介绍 real system

RealNetworks公司是世界 领先的网上流式视音频解决方案的提供者,提供从制作端、服务器端到客户端的所有产品。它的客户端播放器 Realplayer的全球注册人数已经超过了一亿六千万人。ReaNetworks公司最新的网上流式视音频解决方案叫RealSystem IQ，RealSystem IQ容易安装，在高低带宽均可提供良好的视音频质量，但价格较贵。作为流媒体领域的主导厂商，ReaNetworks公司凭借其优秀的技术,占领了一多半的网上流式视音频点播市场。
2 RealSystem系统组成
　　RealSystem IQ由服务器端流播放引擎(realserver)、内容制作、客户端播放三个方面的软件组成：

制作端产品：RealProducer 有初级版(Basic)和高级版（Plus）两个版本。RealProducer的作用是将普通格式的音频、视频或动画媒体文件通过压缩转换为 RealServer能进行流式传输的流格式文件。它也就是RealSystem的编码器（encoders）。 RealProducer是一个强大的编码工具，它提供两种编码格式选择： HTTP 和SureStream，能充分利用RealServer服务器的服务能力。
服务器端产品：服务器端软件RealServer用于提供流式服务。根据应用方案的不同，RealServer可以分为basic、plus、intranet和professional几种版本。代理软件RealSystem Proxy 提供专用的、安全的流媒体服务代理，能使ISPs等服务商有效降低带宽需求。
客 户端产品：客户端播放器RealPlayer分为 Basic和Plus两种版本，RealPlayer Basic是免费版本，但RealPlayer Plus不是免费的，能提供更多的功能。RealPlayer既可以独立运行，也能作为插件在浏览器中运行. 个人数字音乐控制中心RealJukebox能方便地将数字音乐以不同的格式在个人计算机中播放并且管理。

3 RealSystem的通信过程与协议
3.1 RealSystem通信使用的通道和协议
　　RealServer 使用两种通道与客户端软件realplayer通讯：一种是控制通道，用来传输诸如"暂停"、"向前"等命令，使用TCP协议；另一个是数据通道，用来传 输实际的媒体数据，使用UDP协议。 RealServer主要使用两个协议来与客户端联系： RTSP (Real Time Streaming Protocol) 和 PNA (Progressive Networks Audio).

在RealSystem中，通信过程可分为两部分：

Encoder与RealServer之间的通讯
　　当Encoder需要向RealServer传输压缩好的数据时，通常使用one-way(UDP)与RealServer通讯。而一些防火墙通常禁止UDP数据包通过，因此，RealProducer可以设置成使用TCP协议的方式向服务器传输数据。
RealServer与RealPlayer之间的通讯
　　当用户在浏览器上点击一个指向媒体文件的链接时，Realplayer打开一个与RealServer的双路连接，通过这个连接与RealServer之间来回传输信息。一但RealServer接受了客户端的请求，它将通过UDP协议传输客户请求的数据。
3.2 RTSP通信
3.2.1 Realplayer播放过程
　 　如图10-2 所示，浏览器通过HTTP协议向RealServer服务器发出请求，URL请求中包含激活RAMGEN的参数。 指向被请求SMIL文件的URL引发RAMGEN自动产生一个包含SMIL文件位置的RAM文件，这个RAM文件将被传送给浏览器。 RAM文件的扩展名（.ram 或者.rpm）将使得浏览器激活RealPlayer程序。

　　RealPlayer接受浏览器传递过来的RAM文件，然后用RTSP协议与RealServer进行通讯，请求该RAM文件中包含的SMIL文件。 根据在SMIL文件中包含的信息，Realplayer向RealServer请求、接受并播放媒体元素。
RTSP 通信数据包格式
　 　RealNetWorks公司在RealSystem系统中率先实现了RTSP标准协议通信。RTSP 协议通信是一种有状态的通信，在语法及操作上均与HTTP/1.1很相似，但仍有许多方面区别很大，如RTSP 服务一般需要保持状态，而HTTP本质上是无状态的。
对于 RTSP通信, 数据可以通过不同的协议进行传输（如 RDT或 RTP）。目前，RealServer通过标准的实时传输协议RTP和Real数据传输协议RDT两种数据包格式将流媒体数据发送到RTSP客户端。
1.标准RTP通信
　 　RTSP 客户端在UDP上使用RTP协议与RTSP服务器通信时建立三个网络信道，如图所示：全双工TCP连结用来进行控制、协商，单工UDP信道用来使用RTP 包格式传送媒体数据。全双工UDP信道访问RTCP用来向客户端提供同步信息，将包丢失信息发送给服务器。

2.RealNetworks' RDT
　　当数据使用RDT发送时，RTSP 客户端与RTSP服务器通信时建立三个网络信道，如图所示：
　　全双工TCP连结用来进行控制、协商，单工UDP信道用来使用RTP包格式传送媒体数据。另一条UDP信道客户端用来向服务器请求重发送丢失的UDP媒体数据包。

5.3 RealServer 中的组播（Multicast）
5.3.1 简介
　　RealServer中的组 播是将一个现场直播流同时传递给多个客户端，而无需为每一客户的连结发送一个单独的数据流，客户端只需连结到这个数据流，而不是连结到 RealServer服务器，从而降低带宽的使用。为了利用组播技术所带来的优越，在RealServer与Realplayer客户端之间的所有设备必 须是支持组播技术的，包括之间的路由器、交换机、和其他的网络设备。正是由于这个原因，组播通常用在Intranet环境中。RealServer的组播 有两种：反向信道组播（back-channel multicast）和可伸缩组播（scalable multicast）,这两种方法可同时使用。
5.3.2 反向信道组播（back-channel multicast）：
　 　反向信道组播（back-channel multicast）在客户端和服务器之间保持一个用于统计和控制信息交互的控制信道如图10-11所示，由于客户端和RealServer之间的信息交 换是双向的，从而能发送验证信息、用户统计及服务质量信息等，象RealSystem管理器中Java Monitor之类的监视工具可以显示客户端的情况。反向信道组播（back-channel multicast）的访问可以使用RTSP 或PNA协议，RTSP组播比PNA组播多提供一项智能流（SureStream）功能，两者均提供验证和连接统计功能。

5.3.3 可伸缩组播（scalable multicast）
　　与反向信道组播，可伸缩组播没有控制信道，所以这种方法占用 更少的带宽，RealServer的系统资源使用也少。由于没有控制信道，Java Monitor之类的监视工具就不能跟踪用户的活动，用户统计也只能在组播结束或用户停止播出或关闭RealPlayer播放器时。
　　由于传输是单向的，可伸缩组播能向无限的用户播放。提供验证、连接统计和智能流功能。如图

　　可伸缩组播使用不同于RTSP组播或 PNA组播的URL格式，用户连接到可伸缩组播是通过点击 会话描述协议文件（SDP）的链接，此文件是用户点击链接时，RealServer自动产生的。

5.2 RealServer中的分流技术（splitting）
　　RealServer中使用分流技术 （splitting）在服务器之间传输直播数据。Splitting方法可以解决RealServer超负荷的问题，使得客户端可以就近访问 realserver服务器，获得更好的访问质量，并且减小带宽使用，服务更多用户。Splitting技术可以采用UDP单播、UDP组播和TCP三种 方式进行通信。通过分流，一个或者多个RealServer服务器加入到transmitter中，来分散transmitter的流数量，而不是所有的 请求都到达一个RealServer服务器。

　　如图所示：实况内容源 处的RealServer是发送服务器（transmitter），它将实况播放给其他RealServer服务器接收，接收的RealServer服务 器(receiver)一般更靠近访问者。网页上的链接指向接收的RealServer服务器而不是发送服务器。当用户点击链接时，接收服务器识别出特定 的URL，然后把从发送服务器来的视频流转播给用户。
当transmitter开始播放实况流，它将节目广播给所有的receiver。当用户从receiver上请求一个播出节目时，transmitter和receiver之间已经建立了一个连结，播出节目也就立即发送到用户。
　　RealSystem 8中有两种分流方法: 推(push splitting)和拉(pull splitting)。
推 模式要预先建立一个连接，所以第一个客户端的连接不用等待。当等待listen的过程中要占用带宽。当一个客户端请求一个媒体文件时，由于 transmitter和receiver之间的连接已经建立，所以可以立即传送媒体流，这是RealSystem 8 的缺省方式。
　　拉模式 不需要预先建立一个连接，当第一个连接建立后要保持该连接，除非编码器停止编码。第一个请求的客户端必须等待30秒或者一个连接建立。一个连接请求将列出 包含该媒体文件的transmitter和receiver之间的名字，当一个receiver收到一个传送文件的请求时，将向transmitter请 求打开一个媒体流，RealServer将媒体流发送给splitter,splitter再将媒体流发送给客户端。这两种方法可以同时使用。
　　RealServer 8.0 版本与以前的版本有些不同，transmitter和receiver之间能通过组播通信，以节约带宽。

6 RealServer的系统需求

支持的操作系统及硬件

Processor Operating System
1、Intel Pentium Windows NT 4.0 or 2000 Workstation or Server, Linux 2.2 (glib c6), Free BSD 3.0

2、Sun SPARC Solaris 2.6, 2.7, 2.8
3、IBM RS/6000 PowerPC AIX 4.3
4、HP PA-RISC 2.0 HP-UX 11.x
5、R4000 running MIPS3 instruction set
IRIX 6.5

内存需求
　　在原先RealServer占用的64MB可用内存基础上，每kbps数据流还要占用12K的内存。
例如：
　　20kbps需占用240KB的内存
　　100kbps需占用1200KB的内存

以下是比较常见的算法 [ 省略 请参考NO.01 和NO.02 ]

存储需求
　　RealServer本身大约需要8MB的存储空间和另外的媒体数据流所需空间，算法如下：
　　磁盘空间＝数据流速率×所需时间(s)÷8
对于自适应流式媒体文件的算法相对更困难一些，要求对每个嵌入式速率都进行运算。

列表 [ 省略 请参考NO.01 和NO.02 ]

WebServer的要求
　　RealServer与现有的大部分WebServer都是互相兼容的，并且支持MIME格式的建立。已经过测试无误的所有WebServer如下：
　　　　Apache1.1.1
　　　　CERNHTTPDversion3.0
　　　　EMWCHTTPSversion0.96
　　　　HTTPD4Mac
　　　　MacHTTP
　　　　Microsoft Internet Information Server
　　　　NCSAHTTPDversions1.3or1.4
　　　　Netscape Netsiteand Netscape Enterprise Server
　　　　0'Reilly Website NT
　　　　Spinnerversion1.0b12through1.0b15
　　　　WebstarandWebstarPS