首页

 
 

 


 

多媒体技术论文：

多媒体技术

第一章 绪 论

1有关多媒体的基本概念

?多媒体信息处理技术：是指能够同时捕捉、处理、编辑、存储和播放两种以上不同类型信息媒体的技术。常见信息媒体类型包括：文本、图形、图像、动画、音频、视频等。
? 静态媒体与连续媒体：
静态媒体（如文本）是没有时间维的媒体，即其播放速度不会影响所含信息的再现。
连续媒体（如视频和音频）是由媒体“量子”（如音频采样和视频帧）组成的，具有隐含的时间维，播放速度影响其所含信息的再现，因此，需要在一段特定的时间里按特定的速度播放；如果播放速度得不到满足，媒体信息的完整性就会受到影响。
? 捕捉媒体与合成媒体
捕捉媒体是指从现实世界中捕捉到的真实媒体信息。
合成媒体是指通过计算机合成的媒体。

2单机与网络化多媒体

单机多媒体是指完全由本机提供多媒体应用所需的全部资源。例如，基于计算机的培训与教育（CBT与CBE）、多媒体制作、多媒体写作、多媒体演示。多媒体计算机
网络多媒体是指基于计算机网络（LAN，MAN，WAN）的多媒体应用。例如，多媒体电子邮件、计算机会议、Internet电话，等等。多采用客户/服务器模式，也有对等模式。

3多媒体应用领域

? 多媒体出版
? 多媒体办公自动化系统
? 计算机会议
? 多媒体信息查询系统
? 交互式电视与视频点播
? 交互式影院与数字化电影
? 数字化图书馆
? 家庭信息中心：回家工作
? 远程教育
? 远程医疗
? 计算机支持下的协同工作（Computer Supported Cooperative Work）
? 媒体空间（MediaSpace）与赛博（CyberSpace）空间
将办公室、公共活动区、公共资源设备等通过计算机网络互联起来，形成超越时空距离的环境，供工作人员交换信息、传递数据或进行讨论，就形成了所谓的媒体空间。
当媒体空间发展到相当大的范围，信息内容极其丰富，用户访问的界面更加方便而且更具沉浸感时，就成为赛博空间。
? 虚拟现实（Virtual Reality）

第二章 数字化多媒体系统

1基本概念

计算机化的数字式多媒体信息系统。
数字式不等于计算机化。例如，数字式影碟机就不能称为是数字化多媒体系统。

2基本特征

? 计算机化
至少对终端用户来说媒体信息的播放是由计算机控制的。
? 集成化
涉及的设备的类型与数量尽可能地单一。包括存储集成化、捕捉集成化、播放集成化、网络集成化（ISDN与ISPN）
? 数字化
主要是指媒体信息表示的数字化
模拟信号-->数字信号：采样、量化、编码、AD/DA
优点：有利于计算机化与集成化，方便存储、传输与处理
缺点：失真
权衡：数字化的精确性（采样速率与编码位数）与（存储器与网络）带宽
? 交互性
四种用户定制化程度：媒体播放开始时间、媒体播放次序、媒体播放速度、播放形式

第三章 常见媒体类型

1文本

? 非格式化文本：可以使用的字符个数有限（即简单的字符集，如ASCII）而且通常字符的大小固定，仅能按照一种形式和内容使用。纯文本文件
? 格式化文本：字符集丰富（如增加罗马字母、各种特殊符号），多种字体、多种大小、多种排版格式。文本外观可与印刷文本媲美。

2图形与图像

? 图形：是可修正的文件，在文件格式中必须包含结构化信息即语义内容被包含在对图形的描述中，作为一个对象存储。一般是用图形编辑器产生或者由程序产生，因此也常被称作计算机图形。
? 图像：是不可修正的，在文本格式中没有任何结构信息，因此没有保存任何语义内容，作为位图存储。图像有两种来源：扫描静态图像和合成静态图像。前者是通过扫描仪、普通相机与模数转换装置、数字相机等从现实世界中捕捉；后者是由计算机辅助创建或生成，即通过程序、屏幕截取等生成。
象素是图象数字化的基本单位。每一个象素对应一个数值，称为象素的振幅。数字化位数称为振幅深度或者象素深度，如1（黑白图象）和24（真彩色图象）

3视频与动画

?帧：一个完整且独立的窗口视图，作为要播放的视图序列的一个组成部分。它可能占据整个屏幕，也可能只占据屏幕的一部分。
?帧速率：每秒播放的帧数。两幅连续帧之间的播放时间间隔即延时通常是恒定的。
在什么样的帧速率下会开始产生平稳运动的印象取决于个体与被播放事物的性质。通常，平稳运动印象大约开始于每秒16帧的帧速率。
电影24帧/秒。美日电视标准30帧/秒，欧洲25帧/秒。HDTV60帧/秒。
?视频（运动图象）：以位图形式存储，因此缺乏语义描述，需要较大的存储能力，分为捕捉运动视频与合成运动视频。前者是通过普通摄像机与模数转换装置、数字摄像机等从现实世界中捕捉；后者是由计算机辅助创建或生成，即通过程序、屏幕截取等生成。
?动画（运动图形）：存储对象及其时空关系，因此带有语义信息，但是在播放时需要通过计算才能生成相应的视图。通常是通过动画制作工具或程序生成。

4声音

录制、存储、播放与合成

5其他类型媒体

以上媒体类型实质上只涉及到视听。人类的认知媒体除此之外还包括触觉、味觉、嗅觉等。因此，多媒体与多感知是两个不同的概念。

第四章 多媒体数据压缩


1基本概念

数字化的音频与视频信息的数据量极其庞大-->数据存储与网络带宽的压力极大-->需要压缩
多媒体信息存在自然冗余，例如，帧与帧之间的象素具有极大的相关性-->能够压缩
无损压缩与有损压缩
衡量一种数据压缩技术优劣的指标：压缩比、压缩算法是否适于实现、恢复效果

2常见压缩标准

2.1 ISO指定的国际标准

. JPEG标准
JPEG（Joint Photographic Expert Group）小组1991年3月提出了ISO CD10918号建议草案：“多灰度静止图象的数据压缩编码”，用于连续色调灰度级或彩色图象的压缩标准，采用离散余弦变换、量化、行程与哈夫曼编码等技术，支持几种操作模式，包括无损（压缩比2:1）与各种类型的有损模式（压缩比可达30:1且没有明显的品质退化）。
Motion JPEG-->Motion Video
.JBIG标准
JBIG（Joint Bi-level Image Group）是一种无损的二值图象压缩标准。JBIG可以支持很高的图象分辨率，常用的文件格式为1728×2376或2304×2896，压缩比可达10:1。
虽然JBIG是二值图象的编码标准，但是它也可以对含灰度值的图象或彩色图象进行无失真压缩，在这种情况下，JBIG是对图象的每个比特面作压缩变换。
.MPEG系列标准
ISO于1992年制定了运动图象数据压缩编码的标准ISO CD11172，简称MPEG（Motion Picture Expert Group）标准，它是视频图象压缩的一个重要标准。MEPG编码技术的发展十分迅速，从MPEG-1、MPEG-2到MPEG-4，不仅图象质量得到了很大的提高，而且在编码的可伸缩性方面，也有了很大的灵活性。
MPEG-1
是以1.5Mbps的速率传输电视质量的视频信号，其亮度信号的分辨率为352×240，色度信号的分辨率为180×120，每秒25或30帧。MPEG-1标准有三个部分组成：MPEG视频（速率小于1.5Mbps）、MPEG音频（速率为64.2Kbps和19.2Kbps）和MPEG系统（视频和音频的同步）。因此MPEG-1涉及的问题是视频/音频压缩和多种压缩数据流的复合和同步问题。
采用两个基本技术：一是基于16×16子块的运动补偿，可以减少帧序列的时域冗余度；二是基于DCT的压缩技术，可以减少空域冗余度。设计MPEG算法本身面临着一个矛盾：为了满足随机访问的需要，最好对其使用帧内编码，但是，仅靠帧内编码是无法达到在保证画面质量的前提下而满足高压缩比的需要的。因此，MPEG采取了预测和插值两种帧编码技术。MPEG中的DCT技术不仅用于帧内压缩，而且对于帧间预测误差也作了DCT变换，大大减少了空间域的冗余，达到了进一步压缩的目的。
I帧（I-Frame）（Intracoded Frame）：基准帧（reference frame）。
P帧（P-Frame）（Predicted Frame）：只能根据I帧重建，同时作为重建B帧的基准帧之一。
B帧（B-Frame）（Bidirectional Frame）：根据I帧与P帧重建。
MPEG-1是为中等分辨率视频图象制定的一个标准，特别适合于VCD的性能要求。
MPEG-2
1993年ISO/IEC/JTC/SC29/WG11推出的ISO/IEC 13818标准，是一种高带宽的视频数据流标准。MPEG-2既可以工作在隔行扫描模式下，也可以工作在逐行扫描模式下，最多支持5个音频声道，可以实现立体声环绕。MPEG-2提供了较为广泛的应用，典型的应用有HDTV。
MPEG-2标准主要包括四个部分：
1) MPEG-2视频：主要定义了视频数据的编码表示和图象再现的解码方法及过程；
2) MPEG-2音频：主要定义了音频数据的编码表示和音频编码信息的解码方法及过程；
3) MPEG-2系统：该部分定义了包含视频/音频的复合结构，以及实时播放视频/音频所需的时间同步信息；
表2.6 MPEG-2的级别
级 别 最大的分辨率 每秒的点数 传输率
Low 352 x 240 x 30 3.05 M 4 Mb/s
Main 720 x 480 x 30 10.40 M 15 Mb/s
High 1440 1440 x 1152 x 30 43.00 M 60 Mb/s
High 1920 x 1080 x 30 62.70 M 80 Mb/s
4) MPEG-2的一致性测试规范。

MPEG-3：
是为1920 x 1080 x 30Hz的HDTV制定的。后来，人们又发现MPEG-2标准也能够很好地支持这种应用，所以MPEG-3后来成为MPEG-2标准的一部分，称为MPEG-2 High-1440。
MPEG-4
是一种低带宽的视频标准，主要用于视频会议，其视频速率只有64Kbps，分辨率为176 x 144 x 10Hz。极低比特率（Very Low Bit Rate Transfer）

2.2 ITU指定的国际标准

T.120
有关电视会议的国际标准T.120，但不太成功，没有被广泛使用。

标准 功能及定义
T.121 应用程序开发指南，一般应用程序范本
T.122 流向控制及编址，数据及应用程序共用的多点通讯协定
T.123 OSI传送界面，一般电话系统及区域性网络的互联和协定
T.124 会议建立，一般会议控制设定和管理，包括加入或删除参与者
T.125 协定服务的形式，多点通信服务协定规范
T.126 批注及应用程序支持，多点固定图象检测及固定图象批注协定
T.127 将文档传给一方或多方，多点二进制文档传送
T.128 实时音频/图象管理，多点系统的控制

H.320
H.320（其原名为Narrow Band ISDN visual telephone systems and terminal equipment），但是H.320标准还是只适合在ISDN、E1、T1等高速率的数字网上运行，而并不适合于象在电话线这种窄带网上使用。因此，ITU从1993年开始着手制定一套新的标准H.324。

标准 功能定义
H.261 图象数据编码标准，P×64Kbps数字化图象的编码器
G.711 音频编码压缩标准，使用PCM语音频率，需要专用的64Kbps
G.722 音频编码压缩标准，在64Kbps以内的7KHz音频编码
G.728 音频编码压缩标准，以64Kbps的速度使用CELP的语音编码
H.221 帧结构定义，定义传送音频和图象的频道的结构
H.230 系统控制规程的监控与显示标准，音频及图象的同步化控制
H.242 多点桥接的控制标准，可视电话连接及切断标准操作程序
H.233 数据加密
H.231 多点电视会议控制标准，多点控制单元连接规范
H.243 多点电视会议控制标准，多点控制单元协议标准
H.261图象编码器已成为互动式图象压缩的实际标准。它描述帧内和帧间的压缩算法，使用P×64数字通道(64Kbps 到2.048Mbps，即P=1-30)。图象将会及时压缩及解压，这样就将发出方和接收方之间的等待时间减至最低。H.261唯一的缺点是图象的质量低，后面介绍的H.263标准将取代H.261规范。
H.324标准
H.324是通过一般电话线传送音频及视频信息，并对音频及视频信息进行编码及解码的国际标准。一般电话系统获得广泛采用的原因是使用方便，而且有数量庞大的用户。H.324标准可以将电视会议带给数以百万计的、没有加入ISDN的用户。
H.324是为与V.34调制解调器一起使用而设计的。这种调制解调器的总频宽为28.8Kbps，系统设计者可能会选择质量较低的音频，使图象信号能够有较大的频宽。这项标准亦包括动态频宽分配模式，这样音频频宽就能够在没有音频需要传送时给其他数据使用。
H.324的视频编码器规范比起H .320规范有很大的改进。H.263在图象质量方面可能会较H.261高百分之二十至百分之百。

标准 功能及定义
H.263 图象数据压缩标准，以低于64Kbps的速度给数字化图象使用的编码器
G.723 音频数据压缩标准，以5.3Kbps或6.3Kbps的速度进行语音编码
H.245 同步及系统控制
H.223 多用户的多方协定

虽然H.324标准是针对电话线路这种低速率的通信网络制定的，但是由于它采用了很多最新的技术，所以，它肯定也将会取代旧的H.320标准而应用到高速数据网中去，其速率最高可允许2.048Mbps，它的整体框图如图2.13所示。

图2.13 H.324多媒体系统框图

从总体上来看，H.324和H.320的一个重大区别就在于它增加了一个数据通信接口。这是因为H.320主要用在会议电视，H.324则是主要用在多媒体通信，在多媒体通信中，不但要传送电视信号和语音信号，而且还要传送各种计算机数据，尤其是电子通信公告栏的各种数据。具体地说，数据通信接口主要支持多媒体通信的应用，例如电子公告栏，静止图象传输，文件交换，数据库的存取，音频图形会议，设备(如摄像机)的远程控制，网络协议等。所以，它们的最大区别在于H.324不但有视频和音频编码解码器，而且它还有文件会议系统。H.324与H.320之间的另一个区别在于，H.324把数据Modem及其控制也包括了进去。这是因为本来电话网只是一个模拟信号通信网，只有通过数据调制解调器才能把数据信号经过模拟网络来传输。正因为如此，它的多路复用部分H.223，要比过去的H.221复杂(H.221主要是视频和音频信号的多路复用)。其中视频编码解码器H.263实际上是电视信号的压缩和解压缩技术。如果说H.261吸取了MPEG-1的一些优点，则可以认为H.263吸取了MPEG-2的一些优点。
音频编码解码器G.723主要是用来作为语音信号的压缩和解压缩，本来采用G.723编号，但因为后来发现G.723已经作为ADPCM的标准，所以最近可能会改为G.723.1。
标准的数据通信应用包括应用于实时语音图形会议的T.120、用于简单的点对点静止传输的T.84、用于简单的点对点文件传输的T.434、用于远程设备控制的H.224/H.281，以及包括PPP和IP在内的ISO/IEC TR 9577网络协议，用户数据缓存的V.14或LAPM/V.42也包括在内。 最近ITU又对最新标准V.34做了修订，使得它的最高传输速率从28.8Kbps又提高到了31.2Kbps和33.6Kbps。正因为有了这个改进，使得电视电话的传输变得更加方便和现实。

第五章 网络化多媒体

5.1 网络化多媒体应用需求
近年来，随着高速网络技术、多媒体信息处理技术的不断发展，出现了很多网络化多媒体应用，如远程学习、远程医疗诊断、计算机会议系统、视频点播VoD（Video on Demand）等。这些网络环境下的网络化多媒体应用对数据存储技术、数据处理技术、通信技术等都提出了很多新的需求。本节首先介绍网络化多媒体系统中涉及到的一些重要的基本概念，然后从多媒体数据的存储与管理、通信方面出发讨论网络化多媒体应用的基本需求。
一．连续媒体数据基本特征：
．实时性
连续媒体录制设备（如视频摄像机）连续生成媒体量子流，这些媒体量子必须实时录制。例如，满足NTSC质量的视频应用每秒将产生30个视频帧（参见表1.1）。从本质上讲，连续媒体的播放过程是其录制的逆过程，而且应该使用与捕捉媒体量子时所用的相同定时顺序来播放这些媒体量子。对该定时顺序的任何偏离都可能导致不良的后果，例如视频运动中出现的痉挛、音频中出现的间断、甚至音频和视频无法分辨。因此，在处理连续媒体时，必须保持同一媒体内的时间连续性。
．媒体间同步
在多媒体应用中，还必须兼顾不同媒体间的同步问题。例如，播放一部影片，就不仅需要维持视频和音频信号本身的时间连续性，而且需要在视频与音频信号之间进行严格的同步，维持严格的“对口型”关系。又如，在播放动画片时，图象和伴音（包括背景音乐和解说词）之间也必须保持同步。
．高数据传送速率和大存储空间
数字视频和音频播放产生的实时数据的数量庞大，例如NTSC质量的视频每秒产生高达27M字节的数据（参见表1.1），因此，需要网络提供高数据传送速率支持连续媒体的实时传送，需要多媒体服务器和用户工作站具有足够的存储空间存储这些连续媒体数据。这就要求多媒体系统必须高效地实时存储、检索和处理连续媒体数据。
实际上，多媒体信息处理的复杂性主要来源于连续媒体数据，多媒体数据对存储、管理和通信等技术提出的新的需求主要来源于连续媒体。

　表1.1　连续媒体数据类型特征举例

媒体类型 　说明 数据速率
语音质量音频 １个信道，８KHz采样速率，每次采样８位 64Kbps
CD质量音频 ２个信道，44.1KHz采样速率，每次采样16位 1.4Mbps
MPEG-2编码视频 640*480象素／帧，24位／象素，30帧／秒 0.42M字节／秒
NTSC质量视频 640*480象素／帧，24位／象素，30帧／秒 27M字节／秒
HDTV质量视频 1280*720象素／帧，24位／象素，30帧／秒 81M字节／秒

2?等时通信与异步通信

根据媒体类型，我们可以将网络中的多媒体通信分解成以下两类：
．等时通信
等时通信用于在端系统之间传送诸如语音与视频之类需要实时处理的连续媒体数据，生成低延迟、低抖动的连续位流。例如，对于PAL制式的视频信号，网络应该每隔40 ms就向播放场地提交一视频帧；对于NTSC制式的视频信号，网络应该每隔33ms就向播放场地提交一视频帧。由于连续媒体通信具有等时性，因此，通常用“流”（stream）这一术语来抽象表示端到端连续媒体通信。
．异步通信
异步通信用于在端系统之间交换那些不需要实时存储或者处理的静态媒体数据。面向分组的通信技术最适合于这些突发性通信量。
显然，这两类通信必须以并行或者“混合”方式在同一个网络（如100 Mbps 的高速Ethernet、FDDI、B-ISDN等)中传送，才能较好地支持多媒体通信。

3?网络化多媒体应用程序分类

网络环境下的网络化多媒体应用程序可以分成以下四类：
第一类是点对点非实时交互式应用程序，如个人多媒体电子邮件。这类应用程序可以利用现有的点对点通信技术实现，不需要进行实时交互式访问。
第二类是点对多点非实时交互式应用程序，例如多媒体新闻发布。这类应用程序需要将多媒体信息传送到多个目的地，但不需要实时交互式访问。广播可以看做是该类通信的特例。
第三类是实时交互式点对点应用程序，如网络环境下的可视电话。这类应用程序所涉及的通信双方需要进行实时交互式通信。例如，用户可接受的往返延迟一般不能超过800 ms。
第四类是多点实时交互式应用程序，例如桌面计算机会议。这类应用需要在多个参加者之间进行实时交互式通信，而这些参加者可能分散在不同的地点。例如，对于大多数会议应用来说，端到端延迟应该保持在250 ms以下，否则就会使会议参加者感觉信息交流不便利。
显然，具有实时交互作用的第三和第四类应用程序对网络通信系统的要求更高。

二．网络化多媒体应用基本需求

下面，我们就基于客户/服务器模式讨论网络化多媒体应用的需求。图1.1是简化的基于客户/服务器模式的网络化多媒体系统构成逻辑示意图。

媒体服务器
客户机
存储器 缓冲区 网络 缓冲区 播放硬件

图1.1 简化的基于客户/服务器模式的网络化多媒体系统

因此，在设计网络化多媒体系统时，必须考虑以下关键子系统：
?存储与管理子系统：支持多媒体数据的存储、管理、检索与播放。这涉及到媒体服务器与客户端的组织。
?通信子系统：支持客户机与服务器之间的多媒体信息传送。

1?网络化多媒体应用对存储与管理子系统的需求

多媒体数据特别是连续媒体数据对网络化多媒体系统中的存储与管理子系统提出了很多新的需求，要求存储与管理子系统至少应满足如下几个方面的需求：

．实时录制、存取与检索：

视频数字化产生连续记录的视频帧序列；音频数字化则产生连续记录的音频采样序列。由于只有在连续及时播出时媒体量子才能传递其中的含义，因此，多媒体服务器必须保证每一媒体流的录制与播出都是以实时数据速率进行。例如，在录制期间，服务器必须连续存储输入设备（如麦克风或摄像机）产生的数据以防止设备上的缓冲区溢出。另一方面，在播出期间，服务器从磁盘检索数据的速率必须足以避免输出设备（如扬声器或视频显示器）出现“饥饿”。
因此，连续媒体的检索、计算与播放依赖于时间。数据必须在一个严格定义的最后期限之前播放或读取，而且抖动要小。因此，存储与检索连续媒体数据的算法必须考虑时间限制，需要提供附加的缓冲区来平滑数据流。

．文件长度

同文本和图形相比，视频与音频这样的连续媒体数据需要极大的存储空间。多媒体文件系统需要存储的信息的范围非常宽广，从文本文件到视频及其伴随音频文件，因此必须在磁盘上合理地组织数据以便有效地利用有限的存储容量。例如，未经压缩的CD质量的立体声音频实时产生的数据量大约是每秒1.4M位，质量不高但还可接受的MPEG-1压缩视频实时产生的数据量大约是每秒1.5M位，质量较高的MPEG-2压缩视频实时产生的数据量更高。

．多数据流

存储与管理子系统需要在同一时刻支持多种不同的媒体。它不仅需要确保每个媒体流获得足够的资源以保证对其访问的实时性，而且要考虑来自不同源的不同媒体流之间的同步关系。例如，对影片的检索就不仅需要处理视频与音频信息流，还必须对它们进行严格的同步。这就需要存储与管理子系统提供适当的存储、检索与播放机制。
常规的数据存储与管理机制（如UNIX系统的存储与管理机制）难以满足这些多媒体数据特别是连续媒体数据的上述要求。首先是吞吐量不够。例如，多数UNIX系统的文件系统只能同时提交很少的几条连续媒体流。然而，这还不是唯一的问题。现有的存储与管理技术同样不能很好地满足连续媒体的实时性需求。例如，常规磁盘缓存策略就不大适合于连续媒体文件，因为对连续媒体的访问模式通常是顺序的，然而现有系统的策略一般都是为访问具有时间局部性的数据而优化设计的。这些都要求我们重新考虑存储与管理子系统的设计。

2?网络化多媒体应用对通信子系统的需求

通过上面的介绍，我们可以看出多媒体通信的复杂性主要来源于连续媒体。下面，我们就讨论多媒体特别是连续媒体通信的需求。

?压缩与解压缩

我们从表1.1可以看出，多媒体、特别是连续媒体信息源产生的实时数据量非常大，直接进行传送对网络带宽的压力太大。因此，在网络上传送多媒体数据之前，一般都是在信息源对其进行压缩，而在目的地解压缩后播出。图1.2是多媒体数据在网络中传送的示意图。

　

图1.2多媒体数据在网络中的流动

.高带宽

即使是经过压缩之后，多媒体数据、特别是连续媒体数据的网络带宽需求依然相当可观，例如MPEG-1I压缩编码的视频流的网络带宽需求依然高达0.42 M字节／秒。现有的多数网络（10 M bps的Ethernet、4/16Mbps的令牌环、Internet）的带宽难以满足连续媒体数据的实时传送需要，特别是在有多个用户同时需要通过网络实时传送连续媒体数据时更是如此。因此，多媒体通信需要有高速网络技术提供强有力的技术保证。

?QoS支持

服务质量QoS（Quality of Service）说明网络服务的“良好”程度。随着数字视频、音频以及其它连续媒体类型的出现，对QoS支持的要求也不断提高。例如，为了支持视频连接，就需要高吞吐量，因此，必须保证提供高带宽。相比之下，音频则不需要很高的带宽。此外，视频和音频数据都可以容忍一定比例之内的分组丢失与位出错；当然，这也依赖于各媒体数据使用的编码技术。表1.2列出了几种通信量所需的QoS参数值。
为了满足上述需求，多媒体通信网络必须进行必要的增强，以便能够支持更为灵活、更为动态的QoS选择，从而使传送用户可以对传送连接进行适当的剪裁以满足自己的特定需要。在建立连接时，用户应能量化和表达对这些QoS参数的希望值、可接受值和不可接受值。随后，通信双方应该就这些参数进行完全端到端的协商。最终达成一致的QoS参数值应该在连接持续期内得到保证，或者至少在违背协商好的QoS值时应该提供一定的指示信息；前者称为QoS‘硬’保证，后者称为QoS‘软’保证。

　表1.2　QoS参数举例


最大延迟（s） 最大延迟抖动（ms） 平均吞吐量（Mbps） 可接受位出错率 可接受包出错率
语音 0.25 10 0.064 < <
视频（TV品质） 0.25 10 100
压缩视频 0.25 1 2-10
数据（文件传送） 1 - 1-100 0 0
实时数据 0.001-1 - <10 0 0
图象 1 - 2-10


?连接

由于多媒体通信特别是连续媒体通信具有通信量大、实时性强等特点，因此在多媒体通信中一般是使用面向连接的服务而不是无连接服务。同时，在连续媒体通信中，提供单工连接似乎比提供全双工连接更好一些，因为许多连续媒体传送从本质上讲都是单工的。例如，在多媒体会议应用中，远程摄像机到本地视频监视器的连接就是单工的。由于必须为连续媒体连接明确地预约资源，因此，在只需要单工传送的时候使用全双工连接会造成网络容量的浪费。如果需要全双工通信，则通过建立第二条单工连接，通常也可以满足需要。此外，对于连续媒体传送来说，两个方向对服务质量的要求往往不同，例如，我们可能希望在一个方向上传送彩色视频而在另一个方向上传送单色视频，此时，使用两条单工连接就比使用一条全双工连接更为适宜。

?协议与服务类型的选择

网络化多媒体应用的种类繁多、需求各异。例如，仅就带宽而言，一个未经压缩的真彩色视频应用需要高达220 Mbps的传送带宽（即720*512*24位／帧*25帧／秒），而一个电话质量的音频应用只需要64 Kbps的传送带宽。因此，很难设想能有一种全能的通用通信协议可以同样好地满足所有类型通信量的需要。不同类型的通信量和控制数据往往需要不同类型的通信协议，这就要求系统应该能够依据应用通信量的特征为其选择适当类型的通信协议。
除了提供协议类别选择机制之外，为了支持多媒体数据通信，我们还需要对目前OSI标准使用的服务类别概念进行扩充。在当前的OSI框架中，传送服务类别的选择是根据其下的网络服务类型进行的，也就是说，根据网络服务是面向连接的还是无连接的、是可靠的还是不可靠的等因素来选择适当的传送服务类型。对于未来的多媒体应用来说，需要进一步扩充服务类型选择概念，使之包含更多的面向用户的功能。例如，为了提供差错控制领域所需的灵活性，就应该允许传送用户选取符合自己应用要求的差错控制策略，如差错检测与指示策略，差错检测与纠正策略，差错检测、纠正与指示策略，忽略差错策略，等等。

?连续媒体数据传送界面

在传送服务中，常规数据传送界面，例如AT&T系统V传送层界面TLI和BSD套接字（socket）中的send()和recv()之类的调用、OSI中的数据请求data.request和数据指示data.indication原语，对于连续媒体传送来说都不太理想，因为这些界面都没有为连续媒体等时传送服务提供必要的支持。每次数据传送都是独立的，根本不考虑与其前趋和后继的时间关系。对于连续媒体等时传送来说，发送方应该每隔一段特定的时间间隔就发送一个媒体量子，接收方应该每隔一段相同的时间间隔就收到一个媒体量子，这样才能满足连续媒体应用需要。但是，对于到底应该向客户提供什么样的连续媒体数据传送界面还没有达成共识。

?组通信

很多网络化多媒体应用，特别是CSCW领域的应用，都涉及分散的用户组之间的交互作用。在有许多用户同时接收视听信息的多媒体会议系统中就是如此。其它的多媒体应用系统，如共同编辑系统，也有组行为存在。因此，网络化多媒体系统应该支持组（group）概念。这就要求多媒体通信网络必须提供多点播送（multicast）能力，而且为了适应组规模的动态扩张与收缩要求，通信系统还应该支持动态组拓扑结构。

三．网络化多媒体系统模型

综上所述，为了满足网络化多媒体应用提出的新的需求，网络化多媒体系统需要同时在客户机和服务器所在的端系统和连接客户机与服务器的通信网络提供必要的功能来满足这些需求。本节首先讨论适合于网络化多媒体应用的端系统模型，然后讨论适合于网络化多媒体应用的网络化多媒体系统模型。

1．端系统模型
从功能角度来看，网络化多媒体系统中的端系统至少应该具有以下几个模块：获取／输入模块，播放模块，对象处理模块，数据库子系统和通信界面，如图1.3所示。
获取模块与一组输入设备（如键盘，鼠标，麦克风，扫描仪，摄像机等）打交道，负责获取各种媒体类型的数据。
播放模块管理系统输出。对于多媒体信息的播放来说，需要有适当的设备提供物质支持。例如，我们需要有高分辨率显示器来播放高质量的图象。更为重要的是，在播放多媒体信息时，必须对相关的各种媒体信息进行适当的时空同步，才能获得满意的有意义的播放效果。
获取模块和播放模块与媒体类型密切相关，因为它们必须同专门的硬件打交道。
对象处理模块需要执行多种任务。压缩和解压缩就是两项几乎为所有媒体类型都必需的操作。其他功能，例如索引与分类，也可能赋予该模块。对于图象对象，还有很多任务，如平滑与加强，也是必需的。为了进行分段（segmentation）、特征提取和内容描述，还应具备图象分析能力。
多媒体数据库管理系统负责实现DBMS的功能：对象，对象性质，对象之间相互关系的建模；存储系统结构，位置管理与版本控制；安全机制与恢复技术，等等。典型情况下，用户都是通过管理访问和检索活动的查询语言同系统交互作用。
查询模块支持对多媒体对象的检索与处理。用户一般是通过查询或浏览方式访问多媒体系统中的数据。在不能形成精确查询时（多半是由于用户对问题没有精确的认识），用户往往求助于浏览。在许多拥有大量非传统数据的应用领域，如科学数据库中，这样做相当普遍。在多数情况下，用户是想得到有关某个主题的一般信息或者为每个假说寻找支持证据。
对多媒体对象的检索方法可以分成以下四种：
．按标识符（例如索引）检索；
．按条件语句检索；
．借助于例子的相似性检索（similarity retrieval），也称“按实例检索”QBE（Query By Example）；
．按内容检索（或者更为一般地说，按语义检索）。
同传统的数据检索过程不同，对多媒体数据库的检索过程不仅需要考虑如何检索用户需要的数据对象的问题，而且必须考虑如何向用户返回检索到的数据对象的问题。多媒体数据对象通常是由多个数据类型不同的媒体元素组成的聚集单元，元素之间往往存在着复杂的时间与空间同步关系，例如一部影片中的视频和与之相伴的音频之间的“对口型”关系。查询模块必须根据多媒体对象的各媒体元素之间的空间与时间特征，将这些元素有机地从时间和空间上合成起来才能形成一个完整的有意义的多媒体对象并且播放给用户。
通信界面负责与网络打交道，支持多媒体计算机之间的信息交换与共享。
图1.3所示的功能模型提供在互为客户/服务器的对等网络化多媒体应用中的端系统所需的全部功能。在非对称客户/服务器应用中，只需对上述模型提供的功能作适当的剪裁和（或）必要的增强就可构成相应的专用服务器和客户机系统。

通信网络


通信界面

输入 输出


查询模块 用
户

多媒体
存储设备

图1.3 网络化多媒体系统中的端系统功能组成模型

2．网络化多媒体系统模型
根据国内外的研究成果和我们的研究经验，我们认为网络化多媒体系统采用如图1.4所示的结构模型比较合适。

网络化多媒体应用层 系　
网络化多媒体应用支撑平台层 统
协奏层
集成化传送协议层 管
集成式服务网络层 理

图1.4　网络化多媒体系统模型

?集成式服务网络层

该层不仅能够提供诸如文本文件传送之类的传统数据通信服务，而且能够提供涉及音频和视频等连续媒体在内的多媒体通信服务，提供集成式服务。等时Ethernet、快速Ethernet、FDDI-II、DQDB、ATM都可以提供支持网络化多媒体应用的集成式网络服务，提供下层基础网络设施。Internet也在向集成式服务网络方向发展。为此，计算机工作者已经研究出了多种可以支持多媒体通信的网络层协议，例如IPv6、RSVP和ST-2等。

．集成化传送协议层

传送协议层既提供支持连续媒体数据等时传送的高速传送协议、支持媒体内时间连续性的实现，也提供支持静态媒体数据异步传送的传统协议，允许高层对该层协议与服务进行适当的剪裁和配置，以便满足不同应用的特定需要。
HeiTP、RTP、XTP等都是可以支持连续媒体数据传送的协议。

．协奏层

多媒体信息处理的复杂性主要来源于连续媒体数据，在处理连续媒体数据时，不仅需要保持同一媒体内的时间连续性，而且常常需要维持不同媒体间（包括连续媒体之间以及连续媒体与离散媒体之间）的同步关系。协奏层就支持这种媒体间同步（如“对口型”）关系的实现, 提供实时同步机制来控制事件定序和多媒体交互作用之间的准确定时。

．网络化多媒体应用支撑平台层

网络化多媒体应用支撑平台提供一种基于对象的网络化多媒体应用设计环境。在该环境下，用对象来建模组成网络化多媒体应用的各元素，对象之间的交互作用由调用机制提供，从而可以向程序员隐蔽对象的位置。当然，这需要平台提供在分布环境下定位与管理对象的机制。开放分布处理参考模型RM-ODP（Open Distributed Processing Reference Model）为该层提供了一种可资借鉴的模型。但是，由于RM-ODP在制订时并没有充分考虑连续媒体的需要，因此需要对该模型进行必要的扩充才能使之成为充分支持网络化多媒体应用的平台模型。

．网络化多媒体应用层

网络化多媒体应用层向端用户提供各种各样的网络化多媒体应用，如计算机会议、网络化多媒体信息点播、远程学习、远程医疗诊断等。

．系统管理

同传统的分布式系统相比，网络化多媒体系统中的资源的种类与数量繁多、应用的类型与规模庞大，因此系统管理是一个非常重要的问题，必须妥善解决，才能使网络化多媒体应用真正走向实用。
系统管理贯穿参考模型的所有层次，提供保障网络化多媒体系统正常运行所需的各种管理功能。在每一层上，都要配置相应的管理器，彼此协调（包括层间协调和对等协调），共同完成整个系统的管理工作。在网络化多媒体系统中，系统管理不仅要提供传统的管理服务（如配置管理、安全管理、记帐管理，等等），而且必须提供QoS管理机制以便适应多媒体应用的新的要求、特别是连续媒体的要求。其中，故障管理负责检测、隔离和纠正系统中发生的异常操作等；记帐管理通知用户有关资源的使用情况及其所需支付的费用等；配置管理用来设置操作参数、初始化和关闭活动、收集有关运行的数据、改变系统配置、为与各种活动相关的对象集命名等；性能管理通过收集运行数据、维护和考察系统历史日志，对系统的运行情况进行评价等；安全管理提供有关鉴别、授权机制的控制与维护、访问的控制与维护、密钥管理、安全日志的维护与检查等机制；QoS管理负责与QoS有关的各项工作，保障系统提供满足用户需求的QoS，这是网络化多媒体系统有别于传统分布式系统的非常重要的一个方面。

第六章 服务质量

一．QoS概念与现有网络QoS机制的不足

　　近年来，高速网络技术和多媒体工作站技术的飞速进步为网络化多媒体系统的发展奠定了基础，出现了很多新型的网络化多媒体应用，如远程学习、计算机会议、远程医疗诊断、远程多媒体数据库访问、多媒体电子邮件等。用户对这些网络化多媒体应用一般都有一定程度的服务质量QoS（Quality of Service）要求，要求系统对诸如网络带宽、吞吐量、端到端延迟、端到端延迟抖动、分组出错率和比特出错率等QoS参数提供一定的承诺，因此，网络化多媒体系统需要强有力的QoS管理机制来满足用户的要求。
所谓服务质量QoS是指服务性能的聚集效应，它决定用户对特定服务的满意程度。然而，现有网络对QoS概念的支持还比较薄弱。多数网络虽然允许服务用户说明对服务提供方的QoS要求，但是通常并不保证一定满足用户的QoS要求。例如，在IP协议中，只允许IP用户通过IP分组头部中的服务类型域进行简单的定性QoS说明（如低延迟、高吞吐量、高可靠性等），不能进行严格的定量QoS说明，而且下层网络机制也不提供QoS承诺。实际上，现有的多数网络系统在设计时并没有考虑对定量QoS的支持。例如，对于Internet来说，支持可靠的数据传送是它的主要设计目标，提供定量QoS保证仅属次要考虑。
　　其次，多数现有网络中的QoS一般都具有静态性。通信双方一经商定QoS参数值，在通信过程中，QoS参数值始终保持不变，不能对QoS参数值进行动态“再协商”。不经过拆除／重建连接阶段，用户就不能改变连接的QoS，也不能在面对有限资源时重新进行权衡。例如，用户不能选择将已有的一条视频连接的质量从彩色降级到单色，以便打开一条新的音频连接。此外，服务提供方必须承诺在整个连接生命期内提供协商好的QoS。如果不能继续维持协商一致的QoS，服务提供方往往就单方面地关闭连接，因为现有多数网络还没有能将此情况通知用户并允许用户申请可接受的较低QoS水平的机制。
因此，现有网络的QoS管理机制难以适应网络化多媒体系统及其应用的QoS要求，需要有新型的QoS管理机制支持网络化多媒体系统的研究与发展。

二．网络化多媒体系统中的QoS管理基本观点

近年来，随着网络化多媒体系统研究工作的不断深入，人们对网络化多媒体系统中的QoS概念及其管理机制的认识也不断深化，形成了如下基本观点：

1．QoS管理机制面临的新的挑战主要来源于连续媒体

多媒体信息处理技术是指能够同时捕捉、处理、编辑、存储、传送和播放两种以上不同类型信息媒体的技术。这些信息媒体类型包括文本、图形、图像、动画、音频、视频等，可以分成静态媒体（static media）和连续媒体（continuous media）两类。静态媒体（如文本）是没有时间维的媒体，即其播放速度不会影响所含信息的再现。静态媒体也称离散媒体（discrete media）。连续媒体（如视频和音频）是由媒体“量子”（如音频采样和视频帧）组成的，具有隐含的时间维，播放速度影响其所含信息的再现，因此，需要在一段特定的时间里按特定的速度播放；如果播放速度得不到满足，媒体信息的完整性就会受到影响。
　　连续媒体数据的录制、访问、传送与播放过程具有较强的实时性和等时（isochronous）性。例如，NTSC质量的视频应用每隔1/30秒就应产生１个视频帧。这就使得在录制、访问与播放连续媒体时会实时产生很大的数据量，例如未经压缩的NTSC质量的真彩色视频应用每秒可产生高达27M字节（30帧／秒＊640＊480象素／帧＊24比特／象素）的数据量。因此，在网络上传送多媒体数据之前或在多媒体计算机上存储多媒体数据之前，一般都要在信息源对其进行压缩，而在目的地解压缩后播出。图1.2是多媒体数据在网络中流动的示意图。在处理连续媒体数据时，不仅需要保持同一媒体内的时间连续性，而且通常需要维持不同媒体间的同步关系。例如，播放一部影片，就不仅需要维持视频和音频信号本身的时间连续性，而且需要在视频与音频信号之间进行严格的同步，维持严格的“对口型”关系。因此，多媒体信息处理的复杂性主要来源于连续媒体数据，网络化多媒体系统中QoS管理机制面临的新的挑战也主要来源于连续媒体数据。

２．QoS管理应该是可配置的

网络化多媒体应用的QoS需求呈多样化趋势。不同类型的媒体对QoS参数值的要求可能相距甚远。例如，一个未经压缩的NTSC制式的真彩色视频应用需要高达27 M字节／秒的带宽，而一个电话质量的音频应用只需要64Kbps的带宽。不同的网络化多媒体应用对QoS 的具体要求通常也有所不同。例如，实时交互式计算机会议系统对端到端通信延迟要求相当严格，一般要求在250ms以下；多媒体电子邮件则无此严格要求。因此，网络化多媒体系统中的QoS管理机制应该是可配置（configurable），允许用户对系统的QoS管理功能进行适当的剪裁，以便建立与特定应用相适应的QoS级别，满足用户的特定需要。

３．QoS管理应该是完全端到端的

在网络化多媒体系统中，QoS管理还应该建立在从源地到目的地的完全端到端（full end-to-end）的基础之上。例如，一个用于远程视频播放的端到端活动就可能由以下几部分组成：从媒体服务器获得视频，在源地进行压缩，将其传送到目的地，在目的地进行解压缩并根据播放窗口的大小对视频按比例进行调整，最后在视频窗口播放（参见图1.2）。在该端到端路径上，任何一个环节违背了QoS要求，都会损坏播放的完整性（除非其下游环节能够予以补偿）。因此，用户应该从各个环节所支持的QoS中抽象出来，为完全的端到端会话配置QoS；系统应该对涉及到的各个环节进行协调，以确保维持抽象的端到端QoS水平。为了体现完全端到端QoS需求这一概念，同时也为了方便地刻画连续媒体的通信特征，通常使用术语“流”（flow）来表示从媒体数据的产生、传送直至最终消费所经过的完整的端到端路径。流应该由一个QoS语句来控制。

４．QoS管理应该是层次化的

目前，人们还没有就网络化多媒体系统的体系结构参考模型达成共识，即对体系结构到底应该由哪些层次组成、各层的功能及其相互关系是什么还没有达成完全统一的认识。但是，对于网络化多媒体系统应该采用分层体系结构这一点已为计算机工作者们普遍接受。如果将完全端到端的QoS管理观点映射到网络化多媒体系统的分层体系结构上，就形成了层次化QoS管理观点。

５．QoS应该是动态的

在网络化多媒体系统中，仅在会话开始时说明QoS 参数值并且要求它们在会话期间都保持不变是不够的，在实际应用中也不易实现。系统应该提供一种比较灵活的界面，允许用户根据实际情况在会话期间动态地变更QoS参数值。例如，如果由于网络负载的增加而导致系统无法继续维持应用所需的QoS水平，则系统应该通知用户有关QoS降级的必要信息。在此情况下，用户可能并不是简单地关闭该条会话或者只是被动地接受QoS降级，而是可能重新评价各会话的优先级，关闭某个相对次要的会话以释放必要的资源，然后再将发生QoS降级的会话恢复到原先的级别。又如，用户也可能根据实际需要在会话期间主动调整QoS水平，将视频从彩色降级到黑白、将音频从电话音质升级到CD音质，等等。这一切都要求系统提供动态QoS控制能力。

６．QoS承诺

　　为了适应不同的网络化多媒体应用对QoS的不同要求和动态QoS管理的需要，网络化多媒体系统应该提供多种不同的QoS承诺，可以分成三类：
　　．确定型（deterministic）QoS承诺
　　在通信过程中，提供QoS‘硬’保证，确保通信各方协商好的各QoS参数值，不允许有任何违背，否则可能会造成严重后果。这类服务一般用于硬实时应用。例如，远程医疗诊断这样的网络化多媒体应用就需要这类服务来支持诸如患者的X 射线影像数据的实时无差错传送。
　　．统计型（statistical）QoS承诺
　　在通信过程中，提供QoS‘软’保证，允许对通信各方协商好的各QoS参数值有一定比例的违约，适合于软实时应用。例如，对于网络化多媒体信息点播服务中的影片点播来说，用户通常可以容忍一定数量的比特错和帧丢失。
　　．“尽全力”型（best_effort）QoS承诺
　　与数据报服务同义，不提供任何QoS保证。由于带宽的限制，广域网（如Inte）中的网络化多媒体服务多属于这类服务。随着全球信息高速公路的兴起，广域网中的网络化多媒体服务将逐渐向确定型和统计型发展，以提高网络服务的友好性。

三．QoS参数集

不同的网络化多媒体应用的QoS要求不同，因此应该允许用户使用QoS参数来定量和定性地说明各自的QoS要求。在图1.4所示的参考模型中，由于各层的作用不同，因此使用的QoS参数集也有所不同。下面，我们就按照图1.4所示的参考模型自底向上地依次介绍各层所用的QoS参数集。

１．多服务网络层

ITU-T（原先的CCITT）为ATM虚电路制订的QoS参数集是多服务网络层上的一组比较全面的QoS参数，列于表1.3。

２．集成化传送层

该层使用的QoS参数主要有吞吐量、端到端延迟、端到端延迟抖动、出错率和优先级。其中，端到端延迟抖动（end-to-end delay jitter）是指在一条传送连接上T-PDU端到端延迟的最大变化量。例如，在一条连接上T-PDU的最小端到端延迟是2ms，T-PDU的最大端到端延迟是5 ms，则该连接的延迟抖动是3 ms。多媒体应用，特别是实时交互式多媒体应用对端到端延迟有严格限制，不能超过人所能容忍的极限，否则会严重影响服务质量。同样，延迟抖动也必须维持在严格界限之内，否则会造成语音的间断、视频的“痉挛”，从而严重影响人对语音和视频信息的识别。不同的网络化多媒体应用对QoS要求的严格程度不同，因此其优先级应该有所不同，如远程医疗诊断应该比多媒体电子邮件优先获得服务。

３．协奏层

该层的QoS参数应该是最大可容忍的媒体间失步。例如，在高质量远程播放一部影片时，就不仅要求系统提供对组成影片的语音流和视频流的高质量等时传送，而且必须保证语音流和视频流之间的“对口型”关系。还应指出的是，用户对两个媒体流A和B之间的最大可容忍失步程度可能是不对称的。例如，由于人们已经习惯于“观景先于听音”，因此，在播放一部影片时，可容忍的语音对视频的最大超前量比可容忍的视频对语音的最大超前量小；实验结果表明：对于NTSC制式的视频应用来说，前者的值在120ms左右，而后者的值约为240ms。因此，更确切地说，该层的QoS应该用如下两个参数来表示：
　　ahead(A,B)：最大可容忍的A对B超前量；
lag(A,B)：最大可容忍的A对B滞后量。

　　参数名称 　　　　　　　　含义
信元峰值到达速率 应用在峰值负载所需的最大资源。
峰值持续期 最大负载的平均持续期。
平均信元到达速率 源申请的网络资源平均数量。用连接持续期间实测到的信元数量除以这段持续期可得该值。
阵发性 峰值信元速率与平均信元速率的比值。
信元丢失率 丢失信元数目对已传送信元数目的比值。
信元插入率 在信元头部中的地址域因出错而恰好畸变为另一合法网络地址时，就会产生这种类型的错误。
比特出错率 定义为被错误提交的比特数对已发送的总比特数的比值。

　　　　　　　表1.3　ITU-T的QoS参数集

４．平台层

有关该层的QoS应该是端到端的，应用于从源地流经网络直到目的地的完整信息流。在该层次上的QoS参数应当是面向用户的，而不应是面向系统的，低层方面的考虑应当对用户透明，以方便网络化多媒体应用的设计与实现。此外，该层的QoS参数应该是说明性的（declarative），即用户应该说明的是他们需要什么而不是这些需要如何去实现。因此，我们可以考虑将常用的各种QoS水平抽象为各种标准流，例如MPEG-I质量的视频流、MPEG-II质量的视频流、HDTV质量的视频流、CD质量的音频流等，将这些标准流作为QoS参数集，供网络化多媒体应用设计者们选择。

５．应用层

该层应该向端用户提供各种播放片断，例如用来演示具有HDTV质量视频和CD质量音频的影片播放片断等，将这些片断作为QoS参数集，以直观、形象的方式向端用户演示不同的服务质量，供用户选择。
　　注意，应用可能要求QoS管理机制对同一层中各QoS参数提供不同程度的QoS承诺。以传送层QoS参数为例。文件传送应用一般要求QoS管理机制对出错率提供确定型承诺，而对吞吐量只要求QoS管理机制提供“尽全力”型承诺；计算机会议系统通常要求QoS管理机制对延迟、延迟抖动、吞吐量提供确定型承诺，而对出错率一般只要求QoS管理机制提供统计型承诺。
还应指出的是，对于各层所用的QoS参数集目前还没有完全达成共识。我们相信，随着网络化多媒体系统研究的深入，人们逐渐会对QoS参数的最优集合达成共识。

四．QoS管理机制的功能

网络化多媒体系统中的QoS管理机制应该贯穿图1.4所示的参考模型的各个层次，每一层都要有相应的QoS管理器，完成以下功能：

１．QoS协商（negotiation）

　　任何一个网络化多媒体应用的用户都希望网络化多媒体系统提供一定程度的QoS，因此，在使用服务之前，用户应该将其特定的QoS要求通知系统，进行必要的协商，以便就用户可接受、系统可支持的QoS参数值达成一致，使这些达成一致的QoS参数值成为用户和系统共同遵守的“合同”。
在图1.4所示的参考模型中，用户和系统之间的协商包括双边对等协商、层间协商以及三边协商三种类型，如图1.5所示。
双边对等协商是在两个服务用户（一为呼叫方，一为被叫方）之间进行，不允许服务提供者修改由服务用户提出的建议值。双边层间协商在服务用户和服务提供者之间进行。三边协商在两个服务用户（呼叫方和被叫方）以及服务提供者之间进行，每个QoS参数用一个最小申请值和一个上限来表示。在三边协商中，呼叫方的最低目标是获得最小合同值。服务提供者可以朝着上限值方向修改最小值。被叫方作出最后决定，并将最终结果返回给呼叫方。三边协商可以看作是双边对等协商和层间协商的合成。

对等
　（N+1）层　服务用户Ａ　　　　　服务用户Ｂ
层间 协商
协商
　　　 　　 N层　　服务提供者　　　　　服务提供者

　　　 图1.5　协商过程示意

２．QoS的监控、适配、再协商

当用户和系统就QoS达成一致之后，用户就开始使用网络化多媒体应用。在此期间，QoS管理机制需要对QoS合同进行适当的维护，对用户和系统的行为进行必要的监控，以便确保用户不违背协商好的QoS参数值并且确保系统维持协商好的QoS水平。
系统需要监视用户提交的数据量，使之符合QoS合同值的要求，称为通信量“定型”（traffic shaping）。当用户向系统提交的通信量超过QoS合同值时，系统将拒绝传送多出的通信量并且将有关情况通知用户；如果用户不将自己的通信量降至QoS合同值，则系统有权单方面撤回向用户提供的服务，称为通信量“管制”（traffic policing）。
　　如果由于网络负载增加等原因造成系统向用户提供的QoS实测水平低于合同值，则QoS管理机制可以通过适当地调整端系统和网络中间节点的CPU处理能力、网络带宽、缓冲区等资源的分配与调度算法进行细粒度调节，尽可能将QoS实测水平恢复到合同值，此即QoS适配（adaptation）。如果通过QoS适配过程依然无法将QoS恢复到合同值，QoS管理机制就把有关QoS降级的实际情况通知用户。用户可以重新与系统协商QoS，根据当前实际情况就QoS合同值达成新的共识，此即QoS再协商（renegotiation）。QoS再协商的过程实际上是对QoS进行粗粒度调节的过程。当然，用户也可以主动要求提高或降低QoS水平，即QoS再协商也可以由用户主动发起。

３．QoS映射（mapping）

在如图1.4所示的参考模型中，不同层使用的QoS参数集是不同的。因此，在协商和再协商QoS合同值时，需要在层间进行适当的QoS参数集及各参数值的转换。例如，在计算机会议应用中，假定符合NTSC质量的视频流和电话质量的语音流提供的QoS水平属于中等质量的计算机会议。如果用户通过观看相应的演示片断后选择中等质量的QoS，则应用层QoS管理器就要将其转换成平台层所能识别的NTSC质量的视频流和电话质量的语音流交给平台层QoS管理器，如此依次进行下去。通过映射，各层都将获得适合于本层使用的QoS参数，供协商和再协商之用。

４．计费管理

　　无论是局域网环境还是城域网、广域网环境，从向尽可能多的端用户提供服务的角度来看，我们都应该将计费管理纳入QoS管理机制的范畴，将用户所申请的QoS水平和应付的费用有机地结合起来。如果没有计费概念，端用户往往就会选择系统所能提供的最佳QoS而不是可接受的QoS。这通常会大大减少系统可同时服务的端用户数。因此，QoS管理机制应该有计费管理功能，提供面向不同应用的各种不同的计费标准，以便提供“QoS越低、收费越少”的计费策略，从而鼓励用户选择性能价格比最优的可接受的QoS。只有通过引入适当的计费策略，QoS协商才有可能成为真正意义上的协商。

五．QoS管理实现支持机制

1．接纳控制和资源预约

　　在提供端到端QoS管理时，接纳控制与资源预约是基本手段之一。对于确定型和统计型QoS承诺，接纳控制和资源预约是必需的。随着用户数量的增加，网络化多媒体系统的负载将不断升高，其性能最终将达到一个“临界”点；在该临界点处，如果再接纳一个用户请求，就会导致系统过载，以至不能继续满足现有用户和新到来的用户的QoS要求。因此，任何一个提供QoS管理机制的网络化多媒体系统都必须在完全端到端的基础之上提供接纳控制功能，拒绝在临界点处到达的请求。
　　接纳控制通常分两个阶段进行。第一阶段判断能否在完全端到端路径上的端系统和沿途的各中间节点获得所需的资源，这些资源主要包括端系统以及沿途各节点上的处理机时间、缓冲空间和链路的带宽。如果第一阶段成功，则在第二阶段为用户请求预约所需的资源。第一阶段从源向目的地“前向”传播，第二阶段则从目的地向源“后向”传播。如果系统不能按用户所申请的QoS接纳用户请求，那么用户可以选择“再协商”较低的QoS。
接纳控制通过接纳测试来确定资源的可用性。通常，系统至少要进行以下三种不同类型的接纳测试：
．可调度性测试：用于测试共享资源的可调度性。例如，在端系统和网络中间节点上对延迟、抖动、吞吐量和可靠性的CPU可调度性和分组可调度性进行测试。
．空间测试：用于测试缓冲区分配，以便提供延迟和可靠性保证。
．链路带宽测试：用于测试主机总线和网络带宽，以便提供吞吐量保证。
当某个用户请求在端系统和沿途各节点都通过各种接纳测试之后，网络化多媒体系统就应该向该用户提供“先验”性能保证，同时信守对其它用户已经作出的QoS承诺。Tenet方法通过对接纳测试的结果进行数学证明做到了这一点。
如果用户请求通过了接纳测试，系统就要进一步为其预约资源。在多数系统中，资源预约是单工（simplex）的，也就是说，只在源地到目的地路径上沿着一个方向预约资源。预约资源时可以采用两种不同的策略。悲观策略按照最坏情况预约资源，即预约最长的CPU处理时间、最高带宽等，从而避免冲突。这种方法将导致资源的较低利用率，但是可以避免冲突、保证质量，适合于确定型QoS承诺。乐观策略则是基于平均工作负载预约资源，因而资源利用率比较高，但是系统可能出现过载，导致QoS降级。这种策略比较适合于统计型QoS承诺。
对于多数多媒体应用来说，资源预约应该是一种分组交换类型的预约，也就是说，在一用户不使用为它预约的那些资源的时候，其他用户（特别是任务紧急的高优先级用户）应该可以使用这些资源。但是，这会相应地提高系统资源管理的难度。
　　“尽全力”型QoS承诺不需要进行接纳控制与资源预约，因为系统不向需要这类QoS承诺的用户提供QoS保证。用户应用结束后，系统回收相应的资源。

2．基于速率的流控

在网络化多媒体系统中，由于多媒体数据、特别是连续媒体数据的生成、传送与播放具有比较严格的连续性、实时性和等时性，因此源应该以目的地播放媒体量子的速率发送。即使发收双方的速率不能完全吻合，也应该相差甚微。这样才能保证发送方既不会“淹没”接收方，也不会使接收方产生“饥饿”。例如，在NTSC制式下，视频流的接收方应该每秒获得30个视频帧而且应该是每隔1/30秒获得一个视频帧。如果视频帧到达得过早，接收方就需要缓冲它，直到适合该帧的播放时刻到来为止。如果这种局面持续的时间较长，则由于每个视频帧需要的缓冲空间较大，连续缓冲早到的视频帧就会使系统很快用完缓冲区，造成后续视频帧的丢失；如果帧到达得太迟，图像运动就不平稳。因此，为了提供QoS保证、有效地克服抖动现象的发生、维持播放的连续性、实时性与等时性，网络化多媒体系统通常采用基于速率的流控机制，而不是采用传统的滑动窗口机制；这样做不仅可以建立连续媒体数据流与速率受控传送之间的自然对应关系、使发送方的通信量平稳地进入网络以便与接收方的处理能力相匹配，而且可以将流控和差错控制机制解耦。
漏篮（Leaky Bucket）方法是在网络化多媒体系统中比较常用的基于速率的流控方法。使用该方法时，发送方将数据放到篮中。随着在网络上按一定速率发送数据，数据逐渐排出篮底。数据实际离开主机进入网络的速率由位于篮底的调节器控制。篮的尺寸限制因等待网络而累积的数据量。

3．差错控制

多媒体数据在网络上传送时可能会由于噪声的干扰而出现比特错，也可能由于网络带宽、缓冲区拥挤等而出现分组丢失，因此系统应该通过相应的差错控制机制向应用提供所需的端到端出错率保证。在传统的数据通信服务（如文件传送服务、电子邮件等）中，高可靠性至关重要，系统必须保证数据提交的值域正确性。而在网络化多媒体系统中，多媒体数据在目的地的正确提交通常包含两个方面的含义：值域的正确性和时间域的正确性，而且不同的网络化多媒体应用对这两方面的相对重要性的要求也往往有所不同，通常需要在两者之间进行适当的权衡。此外，传统通信服务中的差错控制机制通常只是在较低层（如数据链路层、网络层）上对数据的畸变、丢失、重复、错序等进行检测、指示与恢复，但是在应该对差错控制策略与行为作出决策的高层（如应用层），差错控制机制往往却被忽略了。因此，网络化多媒体系统不能简单地照搬传统数据通信服务中的差错控制机制，不仅需要增加高层的面向应用的差错控制手段，而且应该提供可配置能力，允许端用户对差错检测、差错指示和差错纠正进行适当的组合，以便剪裁出最适合于应用要求的差错控制策略。例如，象音频和视频之类的连续媒体都具有自然冗余性，可以容忍一定比例的的比特错和帧丢失，因此具有一定的内在容错能力。对于一般的视频应用来说，如果某帧丢失，系统可以通过简单地重播前一帧来维持播放的连续性，一般只提供差错检测与指示机制即可。对于某些应用来说，即使不提供任何差错控制机制，用户也可能接受，例如低收费“尽全力”型网络影视播放等。但是，对于诸如远程医疗诊断中的患者X 射线影像之类的实时差错敏感型数据的传送，就需要提供支持高可靠性、实时性与等时性的差错控制机制。
连续媒体及其压缩技术的引入为网络化多媒体系统中的差错检测机制提出了新的挑战。例如，在采用预测编码的视频数据中，如采用MPEG-2编码的压缩视频流，如果其B帧中的AC参数出现了某些差错，就不太要紧，因为其持续时间很短，人眼很难察觉到。但是，如果帧边界被破坏了，则差错无法恢复。因此，系统应该保护数据流中的结构信息。这就需要对现有的差错检测机制（如检查和、数据单元定序）进行必要的扩充，以便携带必要的结构信息。
超时重传机制（包括返回N重传和选择N重传）根本不适应连续媒体通信的实时性和等时性的要求，因为连续媒体播放不能容忍由于超时重传而带来的高延迟。在网络化多媒体系统中，迟到的视频帧和音频帧通常只能被丢掉，其效果等同于帧丢失。预防型（preventive）差错纠正模式，如前向纠错FEC（Forward ErrorCorrection）和优先级信道编码模式比较适合于多媒体通信、特别是连续媒体通信。采用FEC模式时，发送方可以在原始数据流中增加必要的冗余信息，如对关键帧（如MPEG视频流中的I帧）进行复制，以便接收方在检测到差错时立即通过冗余信息进行恢复，这对于端到端延迟保证的实现非常有利。此外，FEC通常不需要在播出之前排他性地缓冲数据，一般也不需要从接收方到发送方的控制连接。但是，增加的冗余信息会相应地提高对系统吞吐量的需求，因此系统需要知道发送方与接收方之间的连接出错概率以及应用所需的可靠性，以便合理地确定所需的信息冗余量，降低对网络带宽的压力。此外，FEC也不能保证一定能从丢失的数据中恢复过来（如果丢失的数据恰好没有进行过复制或者源及其副本一同丢失，就会出现这种情况），因此应该对冗余信息的安排进行优化，尽可能地对关键信息进行复制甚至适当地提高其冗余度，从而提高系统的容错能力。
在优先级信道编码方法中，系统将媒体分成多个优先级不同的数据流，为那些所带信息对于重建原始数据流相对而言比较重要的媒体量子赋予较高优先级，其它媒体量子则赋予相对较低的优先级。例如，对于MPEG视频流，I帧的优先级应该高一些，而P帧和B帧的优先级可以低一些。在拥挤期间，系统首先丢掉低优先级的包。
还应指出，压缩技术虽然大大降低了多媒体数据对网络带宽的要求，但同时也大大降低了多媒体数据的内在冗余性，因此相应地增加了网络化多媒体系统中差错控制实现的难度。

4．调度

调度机制是网络化多媒体系统向用户提供并维持所需QoS水平的又一基本手段，也是网络化多媒体系统的重要研究领域之一。最早最后期限优先EDF（Earliest DeadlineFirst）算法是非常著名的实时调度算法之一。在每一个新的就绪状态，调度器都是从那些已就绪但还没有完全处理完毕的任务中选择最后期限最早的任务，并将执行该任务所需的资源分配给它。在有新任务到来时，调度器必须立即计算EDF，排出新的定序，即正在运行的任务被剥夺，并且按照新任务的最后期限决定是否调度该新任务。如果新任务的最后期限早于被中断的当前任务，就立即处理新任务。按照EDF算法，被中断任务的处理将在稍后继续进行。EDF算法非常适合于周期性实时任务的调度而且可以对任务的处理提供相应的保证。由于连续媒体的生成、传送与播放具有连续性、实时性和等时性，因此媒体量子的生成与处理具有明显的周期性，连续媒体流中的每个媒体量子都有一个隐含的最后期限，基于最后期限来调度进程去处理这些媒体量子非常自然，非常适合连续媒体QoS支持。这样，EDF算法就成为网络化多媒体系统中比较常用的调度算法。
延迟EDD（delay Earliest_Due_Date）算法是对EDF算法的一种扩充。服务提供者按照同每个源协商好的服务合同工作。合同申明，如果源遵守峰值和平均发送速率，服务提供方将保证提供有界延迟。服务提供者根据合同将分组的最后期限设置为应该发送该分组的时间。该时间实际上就是该分组的预计到达时间与交换机延迟界限两者之和。通过预约峰值速率带宽，延迟EDD可以确保每条连接的延迟界限。
抖动EDD（jitter Earliest_Due_Date）算法对延迟EDD做了进一步的扩充，以便提供延迟抖动界限。在为某个分组提供服务之后，交换机就为该分组打上一个“戳”。该戳用来指示该分组的最后期限和实际结束时间之差。位于下一个交换机入口处的调节器在将该分组标记为符合调度条件之前，要将该分组保留戳所指示的那段时间。这样做就提供了最小和最大延迟保证，从而有效地控制延迟抖动。
　　延迟EDD属于工作保养型（work-conserving）调度算法。该类算法总是以较高的速率为分组提供服务，只要这不影响对其它连接的性能保证即可。只要服务用户有分组要发送，服务提供者就不会空闲。抖动EDD属于非工作保养型（nonworkconserving）调度算法。该类算法不是在任何情况下都以较高速率为分组提供服务。使用该类算法时，每个分组都被显式或隐式地分配一个合格时间。在服务提供者空闲时，即使有分组但其合格时间未到，服务提供者也不传送分组。无论是工作保养型调度算法还是非工作保养型调度算法，都可以提供吞吐量保证。
　　网络化多媒体系统中使用的调度算法还有很多，如虚拟时钟（Virtual Clo）算法、加权公平排队WFQ（Weighted Fair Queueing）算法等。

5．同步

　　网络化多媒体应用需要实时同步机制，以便满足用户对媒体间同步的要求，提供协奏层QoS保证。网络化多媒体系统必须提供实时同步机制来控制事件定序和多媒体交互作用之间的准确定时。在网络化多媒体应用中，需要两种风格的实时同步：
　　．事件驱动同步
这是一种通知某一事件或事件集已经发生并且随后导致有关操作或操作集发生的同步操作。由于连续媒体通信的实时性，因此，与事件驱动同步相关的所有操作必须及时完成。例如，如果用户用鼠标点一下与停止视频播放对应的停止图标，视频播放就应该立即停止。又如，在播放到某一视频帧时在屏幕的适当位置叠加字幕，等等。
　　．连续同步
　　当需要将媒体播放设备“捆绑”在一起以便按固定速率播放媒体数据时，连续同步就会发生。视频和与之相伴的音频之间的“对口型”关系就是这种类型同步的典型例子。
一般地，我们可以将在网络化多媒体系统中实现同步的方法分成两类。一类是静态方法。在该类方法中，每个媒体量子（如视频帧或声音采样）都被分配一个时间戳。在播放场地有一个同步实体，该实体的任务就是在指定的时间播放相应的媒体量子。该类方法比较适合于预先定义好的多媒体播放，因为整个播放期间的同步需求都预先知道。但是，该类方法不适合于有动态用户交互作用来改变播放过程的实时交互式网络化多媒体应用。第二类是动态方法。在该类方法中，在播放期间，每当有媒体量子或者有来自用户的交互作用到达时，与之相关的事件就被通知给应用，但是处理这些事件的责任留给了应用程序员。实时语言Esterel可以用来描述和建立任意而且是动态的实时同步控制器，对媒体间同步进行控制并且处理与用户的交互作用。显然，用来实现媒体间同步的机制本身就应该是实时的。

QoS管理是设计网络化多媒体系统时必须解决的主要问题之一。网络化多媒体系统中的QoS管理非常复杂，不仅要支持连续媒体数据生成、传送、访问的连续性、实时性和等时性的实现，还要支持各种媒体之间的同步与集成的实现，因而需要有强有力的QoS管理机制和支持机制实现QoS管理。由于不同网络化多媒体应用的QoS需求不同，因而进一步加大了QoS管理机制设计与实现的难度。如何设计并实现一种通用的网络化多媒体系统QoS 管理机制仍然是一个没有得到很好解决的问题，需要我们进一步探索和研究。


第七章 组与组通信机制


近年来，随着分布式系统的发展，组与组通信机制不仅在传统的分布式组应用领域（如复制文件系统、分布式名字服务系统）中得到进一步发展，而且在新型的网络化多媒体组应用领域（如计算机会议系统、远程学习系统、远程会诊系统等）也日益受到人们的重视。本节介绍组与组通信的有关概念和机制以及多媒体信息对组机制提出的新的需求，以期推动组机制的研究与发展。

一．组与组通信机制基本概念

开放分布处理参考模型RM-ODP将组（group）定义为一些对象的集合，这些对象由于结构上的原因或者是由于其行为具有共性而集结成组[1]。<X>组就是由具有特征关系<X>的多个对象组成的集合。<X>描述对象之间的结构关系或者预期的对象之间的共同行为。例如，编址组就是由按相同方式编址的多个对象构成的集合；通信组是由多个对象组成的集合，这些对象与其所处环境的交互作用序列完全相同；容错复制组也是一种通信组，其目的是提供对某些故障的一定程度的容错能力。
在使用组机制时，客户希望组机制能够实现透明性，即组服务应该提供与单一服务尽可能完全一致的语法和语义，使客户使用组服务就如同使用单一服务一样而毋需知道组内部的协调细节。因此，组需要提供必要的机制来协调参与多方联编的多个对象之间的交互作用。交互作用组是参与由组管理的多方联编的对象的一个子集。对于联编到同一交互作用组的每个对象集合来说，组需要提供如下几方面的管理功能：
?交互作用：根据交互作用政策决定组中的哪些成员参与哪些交互作用。
?整理（collation）：根据整理政策导出交互作用的一致视图。
?定序（ordering）：根据定序政策，确保组成员之间的交互作用排序正确。
?成员属性（membership）：根据成员属性政策确定成员的故障与恢复、成员的增加与删除。组成员关系在某一特定时刻的“快照”（snapshot）称为组视图（group view）。
由于组可以抽象出组成员及其所提供服务的共同特征，可以向客户封装组的内部状态并隐蔽组成员间的相互作用从而向外界提供一致的界面，可以作为构造更大的系统对象的组件块，因此我们可以将相关的对象集结成组。组通信是一种高级的通信抽象机制，可以向应用隐蔽组内部协调工作的细节（如组成员的变化情况），因而可以简化用户程序和组的交互作用，改善通信效率，提高使用通信机制的方便性。
　　实现组通信的方法有三种。第一种方法是使用网络硬件提供的多点播送（multicast）能力实现组通信，通过一次多点播送将一个组报文同时提交给多个接收方，因此可以降低发送方和网络的开销。这是一种比较理想的实现方法，但对分布应用支撑环境的要求较高。第二种方法是利用一对一进程间通信机制实现。这需要发送方追踪接收方组成员的变化情况。此外，该方法的发送方和网络的开销大，因为有多少个组成员，发送方就要发送多少次报文。第三种方法是使用网络广播机制实现。该方法不仅降低了组通信的安全性（组外用户也能收到组报文），而且会增加主机开销（所有上网的机器都要增加相应的“过滤器”以检查到来的报文是否是发往自己所属的组）。
由于组通信机制通常与多点播送机制密切相关，因此在很多文献中两者经常出现混用。我们认为多点播送和组通信是一对需要加以区分的概念。多点播送是一种能将报文从源地发送给多个目的地的网络通信机制，应该有下层基础网络硬件提供相应的支持。同多点播送这种低层网络通信抽象相比，组通信则是一种操作系统级的高层抽象机制，最好有多点播送机制作为其下层实现基础。区分这对概念有助于我们从高层理解组和组通信机制。实际上，组就是由共享相同应用语义、具有相同组标识和（或）同一多点播送地址的对象组成的集合，其中的每一对象都是组的一个成员。

二．组与组通信机制分类

为了更好地理解和应用组与组通信机制，我们有必要对其进行适当地分类。我们基于客户／服务器模式介绍几种分类标准。
服务器组中各成员之间的通信称为组内通信，客户和服务器组之间的通信称为组间通信，如图1.6(a)；由于客户也可以是由多个成员组成的组，因此也可以出现客户组对服务器组的通信，如图1.6(b)所示。
　　　　　　　　　 　
　组间通信　　 服
　　　　　组内通信 务
客
户 器
组
　　(a)

客户组　　　　　　　服务器组
(b)
图1.6　组间通信、组内通信、组对组通信

　　封闭型组只允许组内通信，不允许外界客户对组进行访问，在国防、公安、银行等安全保密性强的部门有较高的应用价值。开放型组不仅允许组内通信，而且允许外界客户以适当的方式访问该组，因此应用场合更广泛一些。
常用的分类标准有两种。一种是根据每个组成员所管理的数据对象以及所支持的对数据对象的操作而将组分成四类：
．数据与操作同构DOH（Data and Operation Homogeneous）型组
组中各成员都维护完全相同的数据对象，支持完全相同的操作。该型组的作用主要是提高服务的可靠性和可用性，如采用对等成员模式的完全复制文件系统。
．仅操作同构OHO（Operation Homogeneous Only）型组
组中各成员所维护的数据对象可能相同、可能不同、可能部分重叠，但各成员支持的对数据对象的操作完全相同。该型组的主要作用是在组成员之间分布工作负载，如部分复制文件系统。
．仅数据同构DHO（Data Homogeneous Only）型组
组中各成员维护的数据对象完全相同，但各成员所支持的操作可能相同、可能部分相同、也可能完全不同。该型组一般是通过相互协作的工作者进程集合提供组服务，如采用主／从模式的完全复制文件系统。
．异构Het（Heterogeneous）型组
组中各成员维护的数据对象和支持的操作可能都是不同的。组成员之间可能存在协作，也可能不存在协作。组成员内部状态可能彼此完全独立。该型组的目的主要是为了方便系统控制并且简化客户与服务器组之间的交互作用，而不是为了提供协作式组服务。Usenet中的新闻组等属于该型组应用。
另一种是根据为客户所见的组的外部行为将组分成确定型组和非确定型组两类。如果组中各成员都必须接收并处理每一个组请求，那么该组就是确定型组。在多数确定型组中，组中各成员是等价的，即各成员在相同的状态下接收相同的请求，调用相同的过程，转换到相同的新状态，并且产生相同的响应和外部影响。对等模式下的完全复制文件系统和复制过程调用等都属于确定型组应用。
非确定型组中的各成员不一定是等价的，因而不要求组中各成员都接收并处理每一个组请求。根据应用的具体要求，每个组成员可以依照各自的功能和当前所处的状态对同一个组请求作出不同的响应。非确定型组可以根据特定的应用环境和组本身的性质适当地放松一致性需求，因此维护开销比确定型组低。V核中的分布式时间服务就属于非确定型组应用。
组是确定型组还是非确定型组取决于使用组机制的应用的特定需求，与其结构特征无关。确定型组主要用于复制数据与服务以增强系统的可靠性；非确定型组主要用于在多个服务器之间分布数据与负载，以实现资源共享并改善服务性能。这两种分类标准也可以分别构成分类矩阵的行和列。例如，对等模式下的完全复制文件系统就属于确定型DOH组应用；采用主／从模式的完全复制文件系统属于确定型DHO组应用；Usenet中的新闻发布应用则属于非确定型Het组应用。

三．设计组通信机制应该解决的问题

由于组机制的客户通常并不关心组的内部结构而只是关心组机制对客户所呈现的外部属性，因此下面我们就针对确定型和非确定型组来讨论设计组与组通信机制时应该解决的问题。

1．确定型组通信机制

确定型组需要完整的组视图以便在组成员之间进行协调与同步，维护强一致性，因此要求组通信具有高可靠性。在设计确定型组时，组通信机制应该满足如下要求：
?组报文提交的原子性和有序性
组报文提交的原子性是指一个组报文要么为服务器组中的所有成员正好接收并处理一次，要么就根本未被服务器组的任何成员接收与处理。原子性通过将部分失败转换成完全失败，向客户隐蔽部分失败的发生。由于组通信系统向组成员提交报文的顺序可能会影响组成员所维护的数据对象在报文处理之后所处的状态，因此组通信系统需要对报文在各个组成员处的提交顺序进行同步。组中各成员需要看到相同的对相关数据的请求序列，并且据此调整其内部状态。因此，报文的提交需要具有有序性。
?应答处理透明性
由于客户和服务器之间的交互作用一般都遵循请求－响应模式，因此只有从客户到服务器的可靠组通信是不够的。要想实现组通信的透明性，还必须正确地收集和处理来自服务器组各成员的应答。这些应答可能完全相同，可能完全不同，可能部分相同。应答处理透明性确保客户毋需知道对其请求可能存在多个应答的事实。客户只看到一个应答，而不必关心该应答是如何导出的（例如，通过加权投票）。
?组命名透明性
这涉及到既动态又透明地将组成员联编到同一个组名字上。组命名机制应该提供如下两种功能：组名对服务器组中各成员的映射；组成员关系动态变化的管理机制。随着成员的故障与恢复、插入与删除等情况的出现，组视图在不断地发生变化，同其他组报文活动并行进行。因此，有关各方都要参与组视图的维护。
由于组报文提交的原子性需要依靠一致的组视图来验证是否所有活跃成员都已确认对每个原子组报文的接收，因此必须以一致的方式检测组视图的变化。在Isis系统中，当有某个组成员出现故障时，系统就代表该故障成员发出一个通告，该通告紧随该成员在发生故障之前发出的所有报文之后。相对于其他组报文，该通告以相同的顺序到达每一个成员，这样，所有成员就在同一“虚拟”时间看到相同的组视图变迁序列。因此，Isis系统可以确保组成员在收到有关某个成员发生故障的通告之后，就再不会收到来自该故障成员的报文。如果故障成员从故障中恢复过来，那么其状态必须及时更新，以便同所属组的最新视图保持一致。
?故障透明性
在发生故障时，系统根据组的意图进行适当的故障处理。当组是用于增强数据可靠性时，如复制文件系统，由于需要在组成员之间维持文件复制品的强一致性，因此通常需要将部分失败放大成完全失败。但是，当组是用来增强服务的可靠性时，例如重复过程调用，维持对客户的服务就是至关重要的；在这种情况下，在故障成员恢复期间，其他活跃组成员应该继续各司其职，以便将损害降低到最低点。
?实时需求
在确定型组应用中，一致性通常比及时性更为重要。当需要在两者之间进行权衡时，系统通常赋予一致性更高的优先级。但是，在实时系统中，报文通常必须在客户指定的最后期限内提交；否则，报文就会过时，系统将触发定时故障。在一对一客户／服务器应用中，服务器可以简单地忽略定时故障报文或者向客户作出操作失败响应。在客户／服务器组应用中，由于网络和服务器负载等因素的影响，有些服务器可能及时收到了报文，而其他服务器看到的却是定时故障；即使是确保原子性和有序性，也可能如此。在发生这种情况时，服务器组中的各成员必须相互协调以便对每个定时故障报文作出一致响应。组通信报文的传送时间应该有界，以便系统可以对组操作进行适当的调度，保证组操作可在同一虚拟时间在所有组成员处原子地进行。

2．非确定型组通信机制

非确定型组可以根据应用的实际需要以各种特定于应用的方式放松对一致性的要求，因此通常只需要基本的多点播送数据报传送支持。
?组报文提交的原子性和有序性
在非确定型组应用中，请求／应答依然是主要的通信模式，但是通常不需要绝对可靠的报文提交或报文定序。在这类应用中，要求客户在服务器组的所有成员达到同步并且准备好接收请求之前一直处于等待状态通常既不必要也不实际。客户通常也不知道服务器组的成员关系情况。有的服务器可能根本就没接收请求。因此，非确定型组通信从本质上讲是异步的。应用本身可能具备方便地检测不一致性并从中予以恢复的能力，数据的一致性不再是一个非常严重的问题。在设计非确定型组应用时，灵活性较强，但要增加处理部分失败的复杂性。
?应答处理透明性
来自非确定型组的多个应答可能是不一致的，通常由客户以特定于应用的方式处理，因而会在一定程度上牺牲应答处理的透明性。
?组命名透明性
非确定型组应用也希望使用逻辑名来标识组服务，因此同样希望能以独立于服务器组成员数目的方式来处理请求和应答。然而，非确定型组的成员关系可能动态地发生变化，而且这种变化通常并不为当前活跃的组成员所知，这就相应地增加了应答处理透明性的实现难度。
?故障透明性
非确定型组成员故障具有同确定型组成员故障不同的语义。在某个成员出现故障时，通常是由其他活跃成员透明地接管该故障成员未完成的任务以增强服务的可用性。
?负载均衡
在非确定型组中，由于缺乏适当的内部协调，因此组成员之间的工作负载可能非常不平衡，需要在应用级提供适当的机制予以解决。

四．多媒体对组机制提出的新要求

　　随着高速网络技术和多媒体工作站技术的不断进步，出现了很多新型的网络化多媒体组应用，对组机制提出了新的挑战。
?多媒体对组机制提出的新的挑战主要来源于连续媒体。
?高带宽
对于网络化多媒体系统中的组应用来说，不仅需要传统的组管理功能和组通信机制，而且需要有高速网络作为其下层基础支撑环境，才能满足其高带宽需求。
?实时性与等时性
基于速率的传送机制
?差错控制
面向应用的差错控制策略、
?压缩和解压缩
压缩技术虽然大大降低了多媒体数据对网络带宽和存储空间的要求，但同时也大大降低了多媒体数据的内在冗余性，因此相应地增加了差错控制的实现难度。
?媒体间同步
?服务质量异构
在网络化多媒体组应用中，由于各成员使用的端系统的能力（CPU处理能力、显示器的分辨率与灰度级、存储器的速度与容量等）、所上网络（ATM、FDDI、FDDI-II、IBM令牌环、Ethernet、快速Ethernet等）的能力以及所愿支付的费用（通常服务质量越高，收费也越高）不同，因此在不同成员处实际达到的QoS水平应该有所不同。如何在同一网络化多媒体组应用中满足不同组成员的异构QoS需求依然是一个值得我们深入研究的问题。

组和组通信机制是分布式系统中的一个非常活跃的研究领域，人们已经取得了很多研究成果，为今后的研究工作打下了良好的基础。多媒体信息处理技术与组机制的结合为分布式系统的研究与发展注入了新的活力，同时也提出了新的挑战。这就需要我们进一步研究与探索，以推动组与组通信机制的发展。


第七章 对多媒体系统的现有支持

7.1 对单机多媒体系统的支持

?硬件：摄像机、麦克风、喇叭、扫描仪、绘图仪、光驱（CD/VCD/SVCD/DVD）、大屏幕高分辨率彩显、高质量彩打、大容量高速硬盘、高速CPU、高速内存、高速Cache
?机器语言级：Intel MMX技术
?操作系统机器级：CPU管理、存储器管理、I/O管理、文件系统管理
操作系统管理计算机资源（CPU、存储器、I/O设备等），隐蔽下层基础设备的物理特征，向端用户提供高效、方便的使用环境。多媒体操作系统需要对传统操作系统的功能进行扩充以满足多媒体数据处理的需要，提供一种既高效支持实时运行多媒体应用也同时高效运行传统应用的环境。要解决的主要问题包括实时处理与基于QoS的资源管理。两者相结合就可以既保证满足多媒体应用的QoS需求且提供对暂态过载的智能控制又满足传统应用的需要，从而使各种类型的应用共存于同一个系统并且都能得到满意的服务。
多媒体操作系统有两种开发模式，一种是扩充传统操作系统，一种是使用微内核体系结构从头构造。在第一种方法中，需要对传统操作系统的内核进行适当的修改以使之能提供可预测的性能。例如，SUN公司认为，目前工作站已具有足够的处理能力，不足之处在于没有适当的资源管理机制。为此，SUN公司开发了一种时间驱动资源管理TDRM（Time Driven Resource Management）机制，允许应用告知系统该应用可能即将到来的资源请求。应用的资源请求用诸如质量、最后期限、优先级等参数刻画。系统并不试图提供性能保证，而只是沿着申请方向有倾向性地分配可用资源，并且将注意力集中在服务的温和降级上，如果用户选用的话，系统还可以将有关降级的必要信息通知受到影响的用户。SUN公司认为，TDRM对于通用多道程序工作站来说是一种适当的策略。第二种方法保留传统操作系统界面，但是采用微内核（micro-kernel）方式重新实现传统操作系统内核结构。Chorus、Mach和Amoeba都是基于微内核的操作系统，并且都支持标准UNIX系统界面。兰卡斯特大学已经研究了如何以Chorus为基础开发提供端到端连续媒体支持的分布式系统。如何在Mach环境下提供适合连续媒体处理的处理机调度机制也取得了显著进展。通过使用基于协处理器的智能设备控制器并且允许应用控制对物理设备的直接访问，在基于Amoeba的UNIX环境下也实现了对连续媒体的支持。
实际上，无论采用哪种方式，多媒体操作系统都必须至少提供满足多媒体信息处理要求的CPU管理、存储器管理、I/O管理和文件系统管理功能。
CPU管理
实时处理可以通过高效实时调度实现。实时调度器调度任务以满足其最后期限。在连续媒体环境下，最后期限可以是可接受的每帧回放时间，因此是一种软最后期限但周期性出现。实际上，多媒体调度面临的挑战来源于两个相互矛盾的目标：
?非实时处理不应该受实时进程执行的影响，因为多媒体应用对离散与连续媒体数据的依赖是等同的。因此，实时进程不应该垄断所有资源。
?应该允许实时进程剥夺非实时进程或者其他低优先级实时进程。
最著名的实时调度算法有EDF和速率单调调度算法[17，18]。对于EDF算法，每个任务都是可剥夺的，而且根据每个任务的最后期限为其分配优先级。分配给最后期限最早的任务的优先级最高。任务的执行按优先级顺序。当有新任务到达时，调度器重新计算所有任务的优先级，然后重新组织处理顺序。如果新到达的任务具有最高优先级，则剥夺正在执行的任务，从而使新任务立即得到服务，被中断的任务以后在中断点处被恢复；否则，新任务将被放到适当的位置上。
对于速率单调调度算法，每个任务都是可剥夺的，而且按照请求速率为其分配优先级。分配给请求速率最高的任务的优先级最高。不同于EDF，这样的分配只在连接建立时执行一次而且维持在整个连接生命期。对于可剥夺、周期性任务，速率单调调度算法在如下意义上是最优的：速率单调算法不能调度的任务集合，其他静态算法也不能调度。
比较这两种算法，EDF更动态一些，因此执行必然频繁，调度开销高，优点是它可以达到100%的处理机利用率。另一方面，速率单调算法是静态的，因为只计算一次优先级分配。由于优先级是根据请求速率分配的，因此速率单调调度算法比EDF的上下文切换多。处理机利用率的最坏情况上限是大约69%（Ln2），尽管平均而言利用率远远超过80%。速率单调调度算法没有调度开销而且对周期性任务是最优。
存储器管理
存储器管理为进程分配存储器资源。连续媒体数据通常都具有比较大的长度而且有严格的定时需求[19]。传统的虚拟存储器采用请求页式调度，不适合这样的实时进程，因为缺页将造成在主存和磁盘之间过长的交换时间，从而可能影响实时性能。一种解决方案是避免交换并且在进程执行期间将连续媒体数据锁在存储器中。但是，这种方法可能影响资源利用率。另一种方法是利用连续媒体数据的周期性及时预取这样的数据。其他比较重要的实用实现技术包括使用散布缓冲区（scatter buffer）以及传递指针。使用散布缓冲区（或者散布装入），就可以将进程地址空间装入可能不连续的存储器区域。这样做的空间效率似乎比单一连续区域高（因为可能得不到连续区域）但可能造成分段。使用指针传递，就可以通过引用传递对象，而不是不得不传递对象本身。同样，这可能导致比较高效地使用存储空间。
I/O管理
I/O子系统的主要功能是在主存和网络适配器或者多媒体外设（摄像机、扬声器、CD-ROM驱动器、麦克风、磁盘、键盘、监视器等）之间传送多媒体信息[15]。重要问题包括设备管理、中断延时与实时传输。设备管理集成所有硬件构件并且为这些设备的控制与管理提供统一界面。通过将物理设备映射成抽象的设备驱动器，I/O管理屏蔽对实际硬件的依赖性。多媒体应用需要大量的I/O操作。连续媒体帧将频繁中断内核，从而降低系统吞吐率。有三种缓解该问题的策略：改变内核的内部结构以使之高度可剥夺、在现有内核中增加安全剥夺点集合、将当前内核转换成用户程序并且在微内核上运行它。实时I/O对于多数多媒体应用是必需的，这样做才能保证每条流的连续性和多条相关流之间的同步。问题的中心围绕着I/O总线带宽。同处理器与存储器性能的提高（预计一到两年提高一倍）相比，I/O子系统性能的提高大为落后。此外，数据在到达目的地之前必须通过一条长通路（例如SCSI总线与系统总线）。这甚至可能导致总线争用。随着网络与通信技术的进步，网络带宽超过1Gbps已经成为现实，I/O已经成为制约系统总体性能的瓶颈，因此提高I/O系统吞吐率迫在眉睫。
文件系统管理
文件管理器负责高效使用存储容量并且向用户提供对存储数据的文件访问与控制。多媒体文件系统还有实时需求以处理连续媒体流。连续媒体对存储系统提出了很多新的要求，常规存储机制（如UNIX系统的存储机制）难以满足这些要求。首先是吞吐率问题。例如，多数UNIX系统的文件系统只能同时提交很少的几条连续媒体流。其次，现有的技术同样不能很好地满足连续媒体的确定性需求。例如，常规磁盘缓存策略就不大适合于连续媒体文件，因为对连续媒体的访问模式通常是顺序的，然而现有策略一般都是为访问具有时间局部性的数据而优化设计的。有关连续媒体存储服务器的研究工作多数是集中在对磁盘布局和磁头调度的研究上。计算机工作者已经提出了多种适合于连续媒体存储与检索的磁头调度算法[20]，如SCAN-EDF算法、Group Sweeping算法等。对于存储布局来说，研究者们提出了多种策略，大体上可以分成以下三类：
?连续媒体单独存储
连续媒体数据单独存放在“专属”的磁盘分区上、或者是“专属”的磁盘上、或者是磁盘阵列的“专属”条纹上，这样就可以对磁盘布局进行高度优化。例如，连续媒体数据可以顺序存放在较大的磁盘块中，从而降低每次访问的搜索时间。连续媒体数据和静态媒体数据的目录信息存放在单独的目录磁盘上。
?连续媒体数据和常规文件一同存放
该策略试图在同一个通用文件系统中同时支持常规文件和连续媒体文件。两种类型的媒体数据存放在同一存储设备上，没有“专属”区域。多媒体文件嵌入在可以同时有效地处理大与小文件系统对象的层次目录结构中。但是，由于两种文件类型访问特征的根本不同，因此任何一种同时为两种类型媒体数据提供支持的通用解决方案都必须进行适当的折衷。高速缓存“除数据之外的任何内容”是一种比较好的策略。采用这种策略，系统只缓存磁头/间接块和目录内容，而不缓存文件内容。这样就可以避免访问连续媒体数据时对Cache的不断“清理”。
?分布式存储体系结构
与连续媒体集成有关的一个主要问题是系统的可伸缩性，即如何为数量日益增长的音频与视频数据既提供足够的存储容量又提供可接受的服务。为了提供这种必需的可伸缩性，有些研究者建议使用分布式体系结构[21]，通过高速网络如ATM网将服务器互联起来。类似于磁盘条纹化，分布式体系结构采用网络条纹化，即将一个源多媒体文件等分到很多条纹单元中去并且将这些条纹单元划分到网络上的多个服务器中去。该体系结构的可扩充性非常好，通过增加新服务器就可以方便地满足未来需求。对于该体系结构，需要进一步研究的问题包括服务器同步、动态QoS管理、负载均衡与可靠性等。
该领域研究工作的具体实例[22]包括加州San Diego大学设计的视频点播VoD服务、加州伯克莱大学开发的连续媒体文件系统、兰卡斯特大学开发的连续媒体存储服务器。后两种系统使用了“磁盘条纹化”（disk striping）技术，即将连续媒体流的连续段存储在磁盘阵列的不同磁盘上。该技术可使N个磁盘提供的吞吐率接近于单个磁盘吞吐率的N倍。但是，值得注意的是，迄今为止，这些技术都不能为同时检索大量的连续媒体流提供完全可伸缩（scalable）的解决方案。

7.2 对网络多媒体系统的支持

一．对网络化多媒体系统的多服务网络支持

网络化多媒体应用的发展推动了网络技术的进步。无论是在局域网领域还是在城域网、广域网领域，网络技术都取得了巨大进步。这些进步使得新型网络不仅能够提供传统的数据传送服务而且能够支持包括音频和视频在内的多媒体信息传送服务，从而使网络向多服务网络方向发展，对网络化多媒体系统的发展提供了巨大支持。
等时Ethernet（isoEthernet）的总带宽为16Mbps，实际上是在现有10Mbps Ethernet的基础之上专门为语音和视频增加了一条6Mbps的同步信道，从而将等时语音和视频流同数据分组分离开来，可以保证语音和视频流实时传送的连续性。等时Ethernet可以使用标准的非屏蔽双绞线作为通信介质。100Base-T快速Ethernet也是使用双绞线作为通信介质，采用集线器（hub）连网，可以提供高达100Mbps的带宽，可以支持网络化多媒体应用。同时，100Base-T与原有的Ethernet标准的兼容性较好，因此，对于保护网络用户的原有投资非常有利。另一方面，由于100Base-T的介质访问控制机制依然属于总线争用方式，因此，对于连续媒体等时传送的支持具有一定的局限性。100Base-VG快速Ethernet则偏离了原有的Ethernet标准，运行在语音级线路上。100Base-VG通过使用专用带宽和优先级协议来支持语音和视频的等时传送，因此可以为网络化多媒体应用的开发提供比较有力的支持。此外，100Base-VG的技术可以在IBM令牌环网上运行，这对于100Base-VG的推广相当有利。目前，100Mbps的快速Ethernet已经产品化，1000Mbps的快速Ethernet也已进入实验室阶段。
当然，作为一种过渡方案，通过对现有局域网进行适当的分段，合理地限制每段局域网中的用户数，也可以使现有局域网支持多媒体通信。例如，从理论上讲，16Mbps的IBM令牌环网至少可以同时传送4路MPEG-II编码的视频流。
FDDI是一种基于ANSI标准化100Mbps令牌环的城域网，可以在200千米距离内支持大约500个工作站。更新的FDDI-II标准明确支持连续媒体数据，具体作法是将可用带宽分成用于连续媒体等时传送的等时部分和用于静态媒体传送的非等时部分，为网络化多媒体系统中的通信提供了强有力的支持。分布式队列双总线DQDB（Distributed Queues Dual Bus）网络是IEEE的标准化MAC层协议，使用一对光纤总线以提高可靠性。DQDB也同时支持等时多媒体数据通信和阵发性较强的异步通信。此外，FDDI和DQDB都支持多点播送（multicast）通信，以支持协作组应用。
ISDN是一种数字化网络，可以支持多媒体通信。拟用于家用的基速率ISDN提供一对64Kbps的载波信道和一个16K／64Kbps的发信信道。主速率ISDN拟用于通信需求较重的用户，提供30*64Kbps信道和一个发信信道。B-ISDN是对ISDN的发展，可以提供极高的数据速率（155Mbps甚至622Mbps、乃至2.4Gbps）。B-ISDN采用ATM分组交换技术实现。ATM使用固定尺寸的信元（cell）而且允许连接的数目和能力可变；每条连接的QoS也是可变的。ATM使用面向连接的呼叫建立过程，在呼叫建立时就在网络交换机中分配资源以支持各连接特定的吞吐量、延时和信元损失需求。ATM也定义了较高层服务，称为ATM适配层AAL（ATM Adaptation Layers）。这些高层服务可以根据特定媒体类型进行适当剪裁，可以支持大分组的分段与重组，提供差错校验与纠正，允许用户选择等时或非等时提交，等等。


Ethernet

令牌环

Internet 隧道
备用隧道
Ethernet 站
mrouted

图1.7 MBONE示意图
MBONE是一个虚拟网络，可以在Internet之上提供多点播送机制，支持网络化多媒体应用。它是由许多具有多点播送能力的网络组成的，其中每个网络上都有一个主机运行多点播送路由选择“守护神”mrouted，通常使用的路由选择算法是DVMRP。不同的mrouted 守护神通过“隧道”相连。本地mrouted 挑出客户发送的多点播送分组，根据路由选择表将它发送到相关的各个隧道。隧道另一端的mrouted 接收该分组，检查其路由选择表，并且将该包转发给隶属于该组的所有成员，而且有必要的话还要向其他隧道转发。图1.7是MBONE的概念拓扑。目前，MBONE已经向用户提供多种视频、音频、白板应用及其工具，例如vat、 nevot、 nv和wb等。


二、对网络化多媒体系统的网络服务支持

　　ITU-T（原先的CCITT)根据通信量的源地和目的地之间的定时关系、比特率以及连接模式，在ATM的AAL层界面上定义了四类服务。其中，A类提供面向连接的恒定比特率CBR（Constant Bit Rate）服务，支持通信量的源地和目的地之间存在的定时关系。这实际上是一种线路仿真服务，可以支持传统的语音传送服务和恒定比特率视频传送服务。B类提供面向连接的可变比特率VBR（Variable Bit Rate）服务，支持通信量的源地和目的地之间存在的定时关系, 用于支持可变比特率视频与音频（例如，采用MPEG编码的视频流）的传送。C类提供面向连接的VBR服务，不支持通信量的源地和目的地之间存在的定时关系，用于提供传统的面向连接的数据传送服务。D类提供无连接的VBR服务，不支持通信量的源地和目的地之间存在的定时关系，用于提供传统的无连接的数据传送服务。
　　Lazer在异步时间共享（Asynchronous Time-Sharing ）网络中也定义了四类通信服务，分别支持线路仿真、语音与视频、文件传送和网络管理流。
Clark则将网络服务分成确保型（guaranteed）服务、预测型（predicted）服务和尽全力型服务，与上述三种服务基本对应。集成化服务体系结构ISA（Integrated Services Architecture-RFC1633）建议对Internet进行适当的扩充，以使Internet既能支持传统的数据通信又能支持象连续媒体通信这样的实时性强的数据流。对于实时数据流，ISA建议使用预测型和确保型服务级；对于传统的数据通信，ISA建议继续使用尽全力型服务。

三、对网络化多媒体系统的通信协议支持

传统通信协议不支持QoS概念，难以适应多媒体通信、特别是连续媒体通信的实时和等时要求。IP是一个无连接的数据报协议。UDP是一个不可靠的用户数据报协议，太弱。TCP是一个完全可靠的面向连接的协议，太强。

1．新型网络层协议

ST-2+（Stream protocol）是一种面向流的协议，目的是为了在Internet上提供诸如网络化多媒体应用等所需的端到端服务质量QoS（Quality of Service）保证。提供的服务是面向连接的，支持多点播送。多点播送数据在一个发送方和多个接收方之间传送。在多点播送情形下，沿着一棵有向多点播送分发树建立多目的地连接。在建立阶段预约必要的网络资源。所有参加方必须就QoS达成共识，即整个流具有相同的QoS。新加入的接收方必须同源建立连接。ST-2+还允许将多条流集结成组，以便共享带宽等。
RSVP（resource ReSerVation Protocol）是一个资源预约协议，与IP配合使用。RSVP分组不携带任何应用数据，只是用来控制IP包的传输。RSVP 中的多点播送基于多个发送方与多个接收方概念。主机首先必须发送一个IGMP分组以加入一个多点播送组。多个发送方可以同时向同一个多点播送组发送。接收方首先根据其QoS需求确定所需预约的资源数量，然后发起预约。RSVP通过中间RSVP代理从接收方沿着子网沿着子网向发送方预约所申请的资源。预约分组朝着发送方传播，直到找到一棵满足需要多点播送树。RSVP预约模型有两个构件组成：资源分配构件和分组过滤器构件。前者确定资源数量，后者选择可以使用资源的分组。RSVP支持三种风格的资源预约：通配符过滤器（wildcard filter）风格，允许来自所有上游发送方的流共享预约的资源；固定过滤器（fixed filter）风格，只允许来自某个特定发送方的流使用预约的资源；共享显式（shared explicit）风格，允许来自挑选出的多个发送方的流共享预约的资源。
8 4 4 112
11111111 FLGS SCOP Group ID
FLGS 000T
图1.8 IPv6多点播送地址格式
IPv6将IP地址从IPv4的32位提高到128位。多点播送地址的格式如图1.8所示，其中高8位都是1；4位的flgs域的前3位是0，后1位是T，若T为0则表示这是一个由Internet权威机构分配的永久地址（即“众所周知”的地址），若T为1，则表示该地址是一个非永久分配的临时多点播送地址；4位scop域是多点播送地址作用域值，用来限定多点播送组的作用范围；112位group ID。112位的group ID既可以是永久的全局标识符，也可以是在指定范围内（如一个组织内或者一个团体内）的临时标识符。簇地址（cluster address）用来到达由共同前缀标识的一簇结点的一个所谓的边界路由器集合中的最近处。这就允许用户选择应该携带数据的提供者。支持多点播送组管理的IGMP已被纳入ICMPv6（Internet Control Message Protocol）。ICMPv6提供三种类型的多点播送组成员属性报文，分别用于组成员属性查询、组成员属性报告和组成员属性减少（Reduction）。IPv6分组头部中的流标签域支持QoS。新一代IP路由器可以根据流标签域中的4位通信量类型子域采取不同的策略和机制处理相应类型的通信量。这对于需要QoS支持的连续媒体流特别有用。

2．新型运输层协议

RTP（Real-time Transport Protocol）为具有实时特征的数据（如连续媒体数据）提供多对等数据传送（如果下层基础网络支持的话）。该协议是为Internet设计的，驻留在诸如UDP、TCP、OSI TP1或TP4、ST-II协议之上。对于多点播送数据传送来说，多点播送地址由发起方获得并且通过带外发信机制分发给组通信的参加者。RTP包在下层基础传送服务的端口上接收，并且封装到下层基础传送系统包中。例如，如果通过UDP传送，则RTP的头部和数据就包含在UDP包中。RTP头部含有定时信息和一个顺序号，支持接收方重建源方所见定时。RTP不提供保证定时提交或QoS保证的机制，也不保证提交或者防止无序提交。RTCP（Real-Time Control Protocol）是和RTP配合使用的“伴侣”协议，提供有关正在进行的会话中的各参加者的信息。若使用RTCP，则每个参加者都周期性地向其他参加者发送本地信息，这些信息作为RTP包中的可选项。 RTCP不必非得使用RTP进行通信。
XTP3.x（Xpress Transfer Protocol）是一个同时具有网络层和传送层功能的协议。如果下层基础网络提供支持的话，则XTP可以提供面向连接的一对多多点播送。为了改善XTP的组通信支持机制，XTP使用四种技术：篮（bucket）算法、时间分片（slotting）、damping（阻尼）和cloning（无性系）。篮算法用来确定如何以及何时更新状态信息。控制信息的处理基于定时器，而且可以做到1-可靠性，即至少有一个组成员收到组通信报文。时间分片和阻尼用来减少控制包的数量。时间分片强制接收方在生成控制包之前必须等待一段随机的时间间隔。差错恢复通过返回N协议进行。如果有错，接收方就以多点播送方式向发送方以及组内其他成员发送差错控制包。如果其他接收方自己的差错控制包包含的值比收到的控制包大的话，就抑制自己的控制包。这就是阻尼技术。使用“无性系”技术，多点播送发送器可以将几个依赖于同一个主上下文的从上下文集结成组。这是一种实现集中的方法，这样，几个发送方就可以向同一多点播送地址发送。XTP.3x没有定义组管理机制。
XTP4.0只是一个传送层协议，因此XTP也变为Xpress Transport Protocol的缩写。XTP多点播送提供从一个发送方到任意多个接收方的单工数据流。单点播送（unicast）控制规程同样适合于多点播送。XTP4.0定义了组管理机制，可以用来确定接收方组的成员属性。这就可以支持多种不同的可靠性语义，即K-可靠性（至少有K个组成员正确地接收到组通信报文）、全可靠性（所有组成员都正确地接收到组通信报文）。对于K-可靠性，XTP4.0还允许指定组报文至少是由指定的某K个成员接收。XTP4.0支持返回N重传和选择重传作为其差错恢复机制。对于可靠的多点播送情形，任何一个接收方报告丢失的数据都必须通过其中的一种差错恢复机制向组重传。时间分片依然用于调节控制包对时间的分布。和单点播送一样，同步握手机制用于信息状态的更新。在同步握手期间，不传送数据。
　　HeiTP是HeiTS系统中使用的一个传输层协议，基于ST-II协议。HeiTP可以支持
数据分组的分段与重组，使用基于速率的流控机制防止发送方“淹没”接收方。差错控制机制是可选的。对于传送中出现的差错，用户可以选择差错忽略、差错指示、差错纠正等机制。此外，HeiTP提供媒体调节机制，可以使被传送的数据流适应网络负载的变化。
　　TP5也是一种支持多媒体通信的传输层协议。对于数据部分，该协议基于ISO TP4协议的机制；对于音频和视频传送，该协议则使用不带出错纠正功能的轻型协议。此外，TP5还提供了在一条传输层连接上同步多条数据流的机制。

第八章 常见多媒体应用

8.1 超文本与超媒体

?基本概念
?Dexter超媒体参考模型
?HTML、HTTP、CGI、VRML
超文本传送协议HTTP（HyperText Transfer Protocol）
HTTP规定了WWW浏览器和WWW服务器之间的交互规则。目前在Web中广泛采用的是HTTP 1.0版本，即RFC1945，它还存在着性能缺陷和功能上的不足。为此，HTTP工作组在1996年6月提出了其新版本 1.1。HTTP具有面向对象的特性，资源对象和相应的操作方法可以一起传送，一个典型的例子是Java字节码传送，它实现了软件在网络上的动态执行。HTTP协议规定了以下主要操作：GET操作，表示以实体的形式取回所标示的任何信息，如果所标示的是一个数据处理过程，比如公共网关界面CGI程序，就返回处理后的数据；HEAD操作，与GET语义基本相同，但是HEAD规定应答消息包中不能含有消息净荷，它经常被用来测试超文本链的有效性、可访问性和最近的修改状态；此外，还有POST操作、PUT操作、OPTIONS操作等。
HTML语言（HyperText Markup Language）
HTML是一种描述性的语言，主要由一些标记(TAG)组成，每个标记都有一个起始标记和终止标记，比如<B></B>是黑体标记，这些标记具有描述从字体到页面排版、图形用户界面元素、各种链接的功能，随着HTML语言功能的不断增强，其标记也在不断扩充。目前在网上广泛应用的是HTML2.0，其标准在RFC1866中定义。HTML的最新版本为3.0，过去叫做HTML+，它解决了2.0的许多局限性和缺点，增强了表格控制功能，增加了数学公式描述等多种标记。
HTML文本的框架如下：
<HTML>HTML起始标记
<HEAD>头部
<TITLE>
…````
</TITLE>
</HEAD>
<BODY> 主体部分
````
</BODY>
</HTML> 结束标志
除了以上表示文本结构的标记外，HTML语言主要还有以下标记：
标题：<H1>、<H2>、…、<H6>
功能：描述各级标题的字体及大小
段落：<P>
水平线：<HR>
预格式化文本：<PRE>,</PRE>
地址：<ADDRESS>,</ADDRESS>
引用标记：<BLOCKQUOTE>,</BLOCKQUOTE>
有序列表：<OL> <LI> </OL>
应用举例：<OL>
<LI> 列表项目 1
<LI> 列表项目 2
</OL>
无序列表：<UL> <LI> </UL> , <MENU> <LI> </MENU>
字体：黑体<B> </B>,斜体<I> </I>
链接：<A>
举例：<A HREF=”http://www.synet.edu.cn”>
图形链接：<IMG>
举例：<IMG SRC=”neusoft.gif”>
表格：<FORM>
公共网关界面CGI
在HTML描述的页面里，为了实现与用户的交互，可嵌入JAVA语言、JavaScript语言等应用，而最基本的方法就是直接利用HTML语言里的FORM这一标记结合CGI程序来实现。
公共网关界面CGI提供了扩充Web服务器功能的一种简便途径，它为HTTP服务器定义了一种与外部应用程序共享信息的方法。当服务器接收到来自某一客户机的请求，要求其启动一个网关程序即CGI脚本时，它把有关该请求的信息综合到一个环境变量集合中，然后，CGI脚本程序将检查这些环境变量，以试图找到那些为响应请求而必需的信息。此外，CGI还为它自己的脚本程序定义一些标准方法，以确定如何为服务器提供必要的信息，如脚本程序的类型。简单地说，CGI程序的工作过程如下：WWW服务器先将从浏览器得到的用户的输入传给CGI程序，做为CGI程序的参数，调用和执行CGI程序，并将其输出结果(HTML文件)返回给浏览器。
CGI的主要用途在于使用户能够编写用于与浏览器相交互的程序。借助CGI可编写用于处理如下工作的程序：动态地创建新的WWW页面；处理HTML表格输入，完成与用户的交互功能；在Web和其他Internet服务之间架设沟通的渠道，如通常见到的应用WAIS、Whois、X.500的界面程序。利用CGI可以实现一些非常复杂的应用，比如WWW与数据库的界面等。
CGI程序是在服务器端运行的，可以利用服务器支持的各种语言来实现，通常有C、C++、PERL、Shell语言、JAVA等。
Web页面中的动画图形制作
在用WWW浏览Internet时，经常会发现一些制作精美的动画图形。这种动画图形可分成以下几种形式：
用JAVA语言的应用小程序(Applet)实现的动画
GIF89a格式的GIF格式图形
MPEG图形
用Java语言实现的动画需编程实现，但其控制和表现比较灵活。GIF89a是GIF图形的一种新格式，它可以组合多幅普通GIF图形，并能控制各幅图形演播时的时间间隔、透明背景等，简单方便，这种动画也是Internet网上最常见的，在网上也可免费得到制作GIF89a格式的工具，比如Gif Constructor等。虚拟现实与VRML语言
VRML
虚拟现实VR（Virtual Reality）是用计算机模拟的三维世界，它具有实时性和交互性两大特点，用户不仅可以浏览、展示虚拟现实所创造的环境，还可以参与到这个虚拟世界中去，达到身临其境的感觉，因此这种技术特别适合应用在做一些需对特殊环境进行模拟的场合，比如汽车驾驶员培训、飞行员培训等。目前，VR技术已被广泛地用来编制三维的仿真游戏，部分这类游戏允许在网络环境下，有多个人参加到所描述的虚拟现实中，达到与现实社会特别逼真的效果。
VRML是虚拟现实的模型描述语言，HTML语言只能描述二维的、平面的页面，而VRML可描述三维的、立体的环境。
VRML是一种将三维数据应用在Web上的规范说明，是一种描述可以通过Internet相互连接和访问的虚拟世界的语言,其目的是通过VRML不仅描述静态事物，同时制作具有复杂动态交互的仿真环境，给用户一种亲临现场的真实感和体验。VRML是在1994年春天在日内瓦举行的第一届WWW会议上孕育，在众多参加者讨论给WWW增加虚拟现实界面的驱使下提出来的,在当时的SGI公司基于ASCII码的Inventor格式的技术基础上发展过来,而后者已具有描述虚拟现实的能力。VRML被设计成为Inventor格式的一个子集并增加了网络支持比如超链接等。
目前使用的VRML规范是1.0版，其最新版2.0正在完善中。VRML规范描述了VRML文件的格式和结构。VRML是一种描述大量对象的属性及相互关系的语言，这些对象可以是3D事物或图象、声音、文本等。在VRML中，这些对象称为“节点”，而一个节点具有以下这些属性：节点类型、节点名字、域、子节点。节点以层次结构组织起来，形成有序的集合，在这个集合中，任何一个在特定位置的节点状态的变化，都会影响所有跟随其后的节点。比如在一立方体节点之前的节点定义了某些旋转和纹理之后会影响该立方体的属性。
象HTML文件一样，要想浏览VRML文件，需要一个VRML的解释器。目前已有的VRML浏览器和在从事开发的厂家很多，有将HTML浏览器和VRML浏览器集成在一起的Netscape公司，其3.0版可通过一个VRML的解释器插件来支持VRML，此外还有Sony公司的CyberPassage、SGI公司的WebSpace等。这些浏览器一般支持对 VRML对象的三维转动和不同角度及远、近视角调整等。
VRML语言中提供了很多描述三维几何体的元素，比如锥体、球体、柱体，文本等，因此可直接利用文本编辑器来创建一些简单的应用，但是对于相对复杂的虚拟现实环境，就只能利用VRML的制作工作来完成，目前已有不少这样的工具，如SGI公司推出的Cosmo World。
下面是VRML语言的一个简单例子：

＃VRML V1.0 ascii
Texture2 {
filename “neusoft.gif”
}
Sphere()

该例展示了一个可放大、缩小、旋转的三维球体，而球体的表面纹理为一幅图。

8.2 虚拟现实
一、概述

虚拟现实VR（Virtual Reality）一词是由美国VPL Research Inc公司的J. Lanier在1989年发明的，通常是指用立体眼镜和传感手套等一系列传感辅助设施来实现的一种三维现实，人们通过这些设施以自然的技能（如头的转动、身体的运动等）向计算机送入各种动作信息，并且通过视觉、听觉以及触觉设施使人们得到三维的视觉、听觉及触觉等感觉世界。随着人们的不同动作，这些感觉也随之改变。它要创建一个酷似客观环境又超越客观时空、既能沉浸其中又能驾驭其上的和谐的人机环境。
虚拟现实有时也译作虚拟实在、灵境、临境。
人工现实（Artificial Reality）、遥在（Telepresence）、虚拟环境（Virtual Environment）、赛博空间（CyberSpace）
虚拟现实系统就是要利用各种先进的硬件技术与软件工具，设计出合理的硬件、软件及交互手段，使参与者能交互式地观察与操纵系统生成的虚拟世界。
虚拟现实系统的三个主要特性：
?沉浸（Immersion）
身临其境，产生在虚拟世界中的感觉，理想情况下虚拟环境应该达到真假难辨的程度，因此理想的虚拟现实系统应该具有多感知能力，提供人类所具有的一切感知能力，包括视觉、听觉、触觉、味觉与嗅觉。
?交互（Interaction）
交互的实时性至关重要。
?想象（Imagination）
思维漫游的理想境界。
参与者在虚拟环境中的活动或经历有两种主要参与形式：
?主观参与（first-person activities）
参与者是整个经历的中心，一切活动围绕参与者进行。
?客观参与（second-person activities）
参与者可以在虚拟环境中看到自己与其他物体的交互

二、虚拟现实系统的分类

?非沉浸类虚拟现实系统：全景视频系统-->实景化虚拟空间、基于座舱的系统、桌面虚拟现实CAD系统、基于剧情的虚拟现实系统
?沉浸类虚拟现实系统：基于头盔的系统、投影虚拟现实系统、遥在系统
?分布式虚拟现实系统
?增强现实系统

三、虚拟现实系统的应用

科学可视化、CAD、飞行、汽车、外科手术的操作模拟、军事模拟与仿真、教育与培训、遥在操作、心理实验床、娱乐、艺术、通信与协同工作

四、虚拟现实系统的组成

1 虚拟现实系统结构

1）?系统感知行为模型
人与外界环境的交互分成两大部分：感知与行为。人通过感觉器官感知外部环境及其变化，通过行为对外界发生作用。
20世纪60年代美国实验心理学家J.Gibson给出了感知系统及行为系统的概念模型。
?感知系统模型
J.Gibson将感知系统分成方向、听觉、触觉、味觉、嗅觉、视觉6个子系统并且分别列出了这些子系统的行为方式、接收单元、器官模拟、器官行为、刺激元与外部信息。
根据J.Gibson提出的6个感知子系统，我们可以为虚拟现实系统设计相应的传感器。
?行为系统
J.Gibson将行为系统分成姿态、方向、走动、饮食、动作、表达、语义七个子系统。其中，姿态子系统用于维持身体平衡；方向子系统用于确定、改变人体的方向；走动子系统用于改变人体在外部环境中的位置；饮食子系统就是人的消化子系统；动作子系统用于改变外部世界；表达子系统用手势、面部表情等传达一定的信息；语义子系统就是语言子系统。
?虚拟现实系统的感知与行为模型
图14.2
技术调制通过技术的方法在虚拟环境中产生现实环境并且合为一体。
从参与者感知接口来看，效应器包括：显示器、语音合成器、运动平台、压感生成器、气味发生器等，传感器包括摄像机、照相机、麦克风、加速计、压力计、温度计以及其他测量仪器。
从参与者行为接口来看，传感器包括跟踪器、数据服装、数据手套、脚踏开关、麦克风等，效应器包括远程控制器、运动平台、光源、声音、环境参数。
非沉浸类虚拟现实系统采用常规显示器，作为观察虚拟世界的窗口。为了增强身临其境之感，通常配合立体眼镜、立体声等。一般使用三维鼠标或者三维操纵杆进行操作，也可以使用数据手套或数据服装。可以采用运动平台反馈运动效果。
沉浸类虚拟现实系统为了达到沉浸的效果，必须把人的主要感官封闭起来，所以需要采用头盔显示器、头部跟踪器、数据手套、数据服装等特殊设备。
2）?虚拟现实系统组成
图14.3
图14.4

2、三维场景建模

?几何建模
?运动建模
?物理建模
?对象行为建模
?模型分割：单元分割与细节水平（Level of Detail）分割
?三维数据格式

8.3 CSCW

8.3.1 CSCW

计算机支持的协作工作CSCW（Computer Supported Cooperative Work）一词最早是1984年由IRENE GRIEF和PAUL CASHMAN俩人提出来的，用于描述他们正在组织研究的如何借助于计算机支持来自不同学科的人们协同工作的课题。
我们知道，每个研究领域都是由一组问题构成的；当研究人员一致认为某一组问题可能拥有相同的特征时，就可以认为出现了一个新的研究领域。在当今的社会生活中，绝大多数工作都是在特定的群体环境中，由群体成员互相协作、共同完成的，人们的工作方式明显地具有群体性、交互性、分布性与协作性等基本特征。随着计算机技术的发展及人们在群体工作中的实际需要，人们已不满足于简单的人机交互，而希望通过连网的计算机促进人与人之间的交流，从而提高群体工作的效率和质量。1986年12月在Texas召开了一次国际性学术会议，集中了社会学家、人类学家、计算机科学家、办公自动化专业人员、人员因素学者及编制设计者等多方面的专家学者，讨论了人类群体工作的特性及计算机技术对群体工作的支持，从而将计算机科学、社会学、编制科学、心理学等多个学科的成果综合起来，产生了一个新的多学科研究领域－CSCW。
目前由于人们对CSCW的含义有不同的理解，对CSCW的定义也各不相同，所以较难给以精确定义，可以简单理解为：CSCW研究群体如何工作，探讨各种技术（特别是计算机技术和网络技术）如何支持群体的工作。在各种有关CSCW的描述中，Bannon和Schnidt在1989年给出的描述有较广泛的影响：
CSCW应致力于研究协同工作的本质和特征，从而以此为基础设计出各种计算机技术支持的信息系统。

8.3.2 CSCW的发展背景

CSCW是以人们协同工作方式为背景，并且以计算机技术、通信技术、多媒体技术的发展为基础而形成的，它具有广泛的应用领域。
M.I.T的Alan Wexelblat曾对计算机与人类活动的关系作出两点论述:
?计算机是用于支持人类活动的。计算机在人类活动中的应用已无所不及，它不仅支持已有的人类活动，而且逐步扩展出许多新型的人类活动。
?人类活动从本质上来说具有协作性。而人具有社会性，绝大多数的工作都是在特定的环境中由群体协作完成的。
从这两点，我们可知，如果计算机要在人类活动中发挥更大的作用，就必须支持协作性的人类活动，对此建立计算机对人类协作活动的支持的理论指导和相关的支撑技术是非常重要的。同时，随着计算机软、硬件技术及网络技术的迅速发展，也为深入开展CSCW的研究奠定了坚实的基础。
首先，计算机系统结构的发展是沿着单机单用户->单机多用户->多机系统->计算机网络->计算机网络互连、互操作和协同工作这个方向进行的,而计算机网络互连、互操作和协同工作构成了实现CSCW的基础结构。
其次，计算机网络技术和通信技术的飞速发展，尤其是高速、远程通信网络技术的发展缩小了时空对人类的限制，一旦实现全球信息高速公路，那么就能真正实现“你见即我见”WYSIWIS（What You See Is What I See)。
再次，计算机学科中多种技术的发展给CSCW的产生和发展提供了一定的技术背景，如计算机技术（高速CPU、大容量存储器、光盘技术、操作系统）、并行处理和分布式处理技术、多媒体技术等。

8.3.3 与CSCW相关的概念

CSCW是一个一般性的概念，CSCW研究群体如何工作、如何共同探讨协作方式，特别是计算机如何支持、 帮助群体工作。 与 CSCW有关的概念有“群件”(Groupware)和“工作组计算”(Workgroup Computing)：
?群件
群件是一种支持一组成员为一个共同任务而工作的计算机软件系统，它提供了支持人们之间的协作工作的环境和工具 ， 同时还提供了对共享环境连接的界面。群件的目的是在通信、合作、协调方面协助群体工作。群件分为“实时群件”和“非实时群件”：专门支持同步行为的群件称为“实时群件”，其它则是“非实时群件”。
在群件概念中，“共同任务”和“共享环境”是很关键的内容。所谓“共同任务”是合作者共同要完成的任务。“共享环境”是合作者所处于的某个可共享的环境，该环境将各种现场信息传送给所有参加者，使他们了解环境的各种情况，以便于协作操作。
计算机支持的协同工作作为一个明确的研究方向已有十多年的研究开发历史，相关的群件产品如Lotus Notes已在设计制造、并行工程、工作流管理、决策支持等方面得到应用。
?工作组计算
工作组计算是指在较小的组织机构中，合作者进行协同工作，共同完成有关的计算任务。
CSCW和群件的关键区别在于：群件往往面向技术，而CSCW更倾向于人类工作的方法和特性的研究,其首要目的并不是设计支持群体工作的计算机系统。

8.3.4 CSCW的研究内容

CSCW的研究目的就是通过充分利用现有的计算机技术、网络技术等，来快速地完成一个共同任务。它主要由两部分组成，即：群体工作过程和支持群体工作的相关技术。
?群体工作方式过程
在CSCW系统的设计中，群体工作过程的研究是非常重要的。群体工作过程主要指群体工作的特点，其中人与人相互之间的交流方式、人与计算机的交互方式是它的核心。CSCW的群体工作过程包括以下四个方面的问题：
协同工作的群体中的个人的工作方式和风格
由于群体工作是由协同工作的个人活动组合成的，所以掌握群体中的个人工作习惯对于设计CSCW应用系统是关键性的环节，这主要包括个人发言方式、个人工作模式以及群体支持系统的界面设计等方面。
协同工作的群体编制
无论大规模的组织、还是面对面会议中的小组，为提高工作效率，群体必须进行编制管理。CSCW研究中有关编制方面的工作涉及编制知识的表示、编制结构的设计及管理等问题。
协同工作的群体工作设计
协同工作的群体需要有效的计划和组织，所以需要确定工作目标、设计工作进程。通用的系统设计方法不适用于群体工作中正式活动和非正式活动相结合的特定模式。目前CSCW学者正着手研究一些适用于群体工作的设计方法。群体工作设计必须让用户亲自参与，设计重点在于建模和可用性测试，同时也需要考虑群体工作过程的其它方面。
协同工作的群体动态
对于协同工作的群体动态的描述，主要是描述群体的运行方式，即人们在群体中如何协同工作，这需要考虑协作的群体的规模、合作的时间、方式及距离，协作的群体性能及群体中个人的行为等相关因素。
?支持群体工作的相关技术
支持群体工作的相关技术指的是用来支持群体工作的计算机技术、网络通信技术以及其他相应的软、硬件技术，它主要包括以下几方面：
高效的通信系统
支持CSCW的通信系统应有效地帮助位于不同地点的协同工作的群体成员方便、快速地交互。现在CSCW研究开发的通信系统有：支持图形、图象和声音的高级Email系统；群体组织信息的X.500 Email目录支持；集成工作站和个人机的实时桌面视频会议系统；大型视频屏幕系统等。
共享工作空间系统
在协同工作时，人们需要良好的共享工作空间。CSCW领域的专家们正在开发远程屏幕共享设施、配置个人屏幕共享和大型公共投影屏的先进会议室、提供制图、列表、综合电子文档及存储、打印等多种功能的智能面板、基于Internet的WEB浏览器等共享工作空间。
共享信息系统
群体工作需要使用共享信息，工作过程中也会产生大量的共享信息，因此需要为协作的群体成员提供支持共享信息的输入、存储及检索的工具。目前已开发的共享信息系统包括：面向多媒体、多用户的超媒体系统；共享光盘系统及各种类型的多用户数据库等。
群体活动支持系统
协作的群体成员需要对工作目的、方法、程序及彼此的任务达成共识，以实现协调、高效的工作。群体活动支持系统为特定的群体活动提供支持，包括过程处理/工作流系统、共同执笔工具及共同决策工具等。

8.3.5 CSCW基本系统的分类

CSCW系统的应用领域广,已经开发出和正在开发各种CSCW系统。如果根据时间和空间概念分类，就抓住了CSCW系统的两个基本特征—交互合作方式和合作者的地理分布。
一?合作形式
CSCW系统的基本目的是支持多用户合作以解决一个或一类特定问题，因其他成员交互方式不同，合作形式可分为以下三类：
?完全同步系统：要求全体用户同时参加，如实时计算机会议系统。
?完全异步系统：允许合作在一段较长时间内发生，如Email系统。
?混合系统：既支持同步合作，也支持异步合作，允许实时同步合作和独立于时间的异步工作发生在同一框架内，如既有异步交互也有同步交互的一般计算机会议系统。
二?地理情况
基于群体的地理分布情况，CSCW系统可分为以下四类：
?当场合作：要求所有用户均在同一地点。
?虚拟当场合作：全体用户不一定都在同一房间内，但系统应用如同当场合作。这类系统通常使用多媒体技术（声音、图象等）。
?局部远程合作：通常所有用户位于同一工作单元（如一座大楼）之内，用户之间通常需共享屏幕，并可提供高宽带实时访问能力。
?.远程合作：适用于群体成员间的相互访问能力很低的情况，包括消息系统及只能采用基本“拨号”机制的计算机会议系统。
三?CSCW系统分类
根据合作形式和地理情况，现有的CSCW系统可以分成四类：
?电子邮件系统：CCITT的X.400是标准的电子邮件系统，多媒体电子邮件系统属于这一类。
?计算机会议系统：多媒体会议系统是对群体成员的协同工作非常具有吸引力的系统。
?会议室系统：支持群体成员面对面实时地进行协同工作和决策，常包含着一个大显示器、计数器、电视终端，若干单独的输入/表决设备及控制终端等。
?协同写作及协同问题讨论系统：支持群体工作的成员协同写作和讨论，合作生成的文件是这种协同工作的产物。

8.3.6 CSCW的关键技术

一?界面技术
CSCW系统的人机界面与单用户系统不一样，它是多用户界面，应能体现群体活动及多用户控制的特征。在CSCW系统中，人机界面带来了单用户界面所没有的许多问题，其中比较典型的是要支持多用户系统特有的协作活动和并发活动所带来的复杂管理。在多媒体网络环境下，多用户、多媒体信息和多窗口的应用程序界面技术，要求能提供支持协同工作的友好用户界面，以便于应用集成、应用管理及用户使用，所以界面技术是CSCW系统的关键技术之一。WYSIWIS是多用户界面设计原则的抽象。
二?协调控制机制
CSCW最本质的特征是支持一组用户协同工作，也就是要为一组用户提供一个协调控制机制。协调机制是用户间约定的交互方式，可完成调度用户活动、分配共享资源等任务。CSCW系统能否成功地支持协作活动，在很大程度上取决于有无良好的协调机制。通过协调机制可以将时间上分离、空间上分布而又相互依赖的多个协作个体的活动有机地联系起来。离开了协调机制，CSCW系统只能是各组成部分毫�