基于net的语音会议系统(毕业设计)_[文档在线提供].doc

南 开 大 学本 科 生 毕 业 论 文（设 计） 题 目：基于.net的语音会议系统学 号：0010202姓 名：严飞年 级：2000级学 院：软件学院系 别：软件工程专 业：软件工程完成日期：2004-6-指导教师：朱耀庭摘要 基于.net的语音会议系统软件学院软件工程系 软件工程专业 许韬 学号：0010690 指导教师：朱耀庭 教授摘要:基于.net的语音会议系统，使用C#编程语言开发。网络通信使用UDP用户数据报传输协议，实现了点对点通信和组播。语音编码解码遵循G.729规范.数据库使用SQL Server 2000.本系统可以使多人同时在线进行语音会议,并可将会议人员分成多个小组进行讨论.关键字：语音技术，网络，语音编解码，数据，服务器，客户端，数据库，一般会议模式，分组会议模式，主持人，发言模式和话权语音过滤，两人秘密通话，系统日志，点对点通信，UDP用户数据报协议，广播，g.729语音编解码规范，数据库设计，规范，SQL Server 2000，ADO.NETABSTRACTAbstractThe Meeting System with Sound is based on .net platform and Programmed in C# language.The net-transpot module obeys the UDP protocol.We realized the Point-to-point communication and Group-broadcasting.The sound coding and decoding module obeys the G.729 coding and Decoding protocol.Data module uses the SQL Server 2000.This meeting system allows multiple persons to have meeting online.And people in the meeting can be distribute in some groups.They can have little discuss in their groups.Key Words：Sound technology , cyber-space , .net , coding and decodingdata , server , client , data-base , common meeting modegroup meeting mode , host , say mode and the right to saysound percolation , secret talk , system log , point-to-pointUDP , broadcasting , group-broadcastingG.729 coding and decoding protocolDatabase design criterionADO.NET, SQL Server 2000第四章题目目 录第一章 绪论11.1语音技术简介32.1系统环境3第二章 系统总体设计32.1系统环境32.2系统软件架构42.3系统逻辑架构5第三章 系统功能设计73.1 功能概要73.2 网络底层技术173.3 语音编解码技术183.4 数据库设计25第四章 系统的应用效果274.1 测试平台架构274.2 功能测试27第五章 总结31致 谢32参考文献33第一章 绪论1.1 语音技术简介近年来互联网飞速发展，各类型网站和互联网应用如雨后春笋般纷纷出现，为了吸引网民的访问，各公司都推出了有自己特色的服务，但都是基于传统文字和图形，而随着上网人数的增长和网民素质的提高，用户对服务提出了更高的要求，不但要求传统的文字和图形，还需要一些更人性化的内容如音频和视频等。现有网络应用上的音频和视频都是基于宽带网的，而现有的网络带宽条件决定了广大的拨号上网用户根本无法享受这些服务，这就造成了很大矛盾，制约了互联网应用的发展。1.2 实现难点要完成本语音会议系统，必须完成如下三个模块：1.2.1) 网络模块本模块要提供底层网络传输的技术支持，主要是数据报的传送，点对点通信，广播，服务器与客户端、客户端与客户端之间的消息传递。1.2.2) 语音编解码模块由于语音直接传输将会占用大量的带宽资源，极易造成网络拥塞，所以在语音信号传送到网络之前必须进行编码压缩，而接收方收到经过编码的信号之后将其解码，还原为语音信号。在编解码的过程中音质会有损失，但在一定范围内这是可以接受的。1.2.3) 数据模块为了能够高效地处理大量会议参加人员的信息，这些信息将被将保存在数据库中。数据的修改，添加，删除等操作都通过数据库来进行。第二章 系统总体设计2.1系统架构服务器客户端结构2.1.1 服务器端服务器端主要功能：与客户端通信，服务器端主持会议。允许一个局域网上存在一台或多台服务器同时运行，允许多个会议同时召开。与数据库连接。客户端登陆服务器之后，参加会议的人员资料由服务器模块存储在数据库中。服务器端可以随时更改数据库中的人员数据。服务器端为会议做一定的限制：如限制在一次会议中或一个组中只能有一个主持人，同时每组只能有一个人发言（拥有话权）等。2.1.3 客户端客户端中包含音频编解码模块，实现具体的语音通信。客户端与服务器端联系。当客户端加入会议时首先到服务器端登陆。在参加会议时如果两个会议参加人员使用秘密通话方式，则由两客户端进行点对点通信，语音信号传输不经过服务器端。2.1.2 数据库数据库存储会议人员的相关资料，如UserName，User Password，group这些会议资料和Job,Department,True-Name这些其他的资料等。数据库由服务器端调用和操作。所有数据库中数据的修改可以是会议进行时由服务器端即时修改，也可以由管理员直接修改编辑。2.2开发环境2.2.1 服务器配置l CPU P4 2.4Gl 内存 512Ml 硬盘 80Gl 声卡l 耳麦（话筒）l 网卡操作系统Microsoft Windows Server 2000 Edition开发平台Microsoft Visual Studio .NET 2003SDKMicrosoft .NET Framework v1.1开发语言C#数据库SQL Sever2000 Standard第三章 系统功能设计3.1功能概要3.1.1 会议目录系统提供同时举行多个会议的功能，并且提供会议目录，以方便会议参加者的进入相应的会议。会议目录是包括了提供会议服务的服务器的计算机名，IP，以及会议名字等信息的列表。3.1.2 会议模式系统提供两种会议模式：一般会议模式和分组模式。) 一般会议模式：会议参加者分成会议主持人和普通参加者。主持人可以控制普通参加者的发言权限。普通参加者只有得到授权才能发言。这种模式比较典型的应用类型为：讲座，远程教育。) 分组会议模式：又称小组讨论模式。在一般会议模式下，与会者分成多个小组，每个小组由会议主持人指定一名小组主持人，小组主持人可以控制组参加者的发言权限。组参加者参加者只有得到授权才能发言。会议主持人可以随时更改小组主持人的权限。) 发言模式和话权一般会议模式下有两种发言模式：按序发言模式和主持人指定发言模式。当主持人指定按序发言模式后，被指定的第一个会议参加者得到话权（即发言的权利）并开始发言，当他结束讲话后，将话权转交给下一名会议参加者。在按序发言模式下，会议主持人随时可以夺回话权并重新分配。任意时刻只允许一个会议参加人员持有话权。分组会议模式下也有按序发言模式和小组主持人指定发言模式，与一般会议模式下的发言模式基本相同。任意时刻每组中只允许一个会议参加人员持有话权。如果有会议参加人员未参加任何小组，则默认其属于0小组，由会议总主持人充当小组主持人。3.1.3 语音过滤会议参加者可以通过界面选择收听/不收听其他会议参加者的发言。会议参加者可以通过界面选择收听/不收听特定会议参加者的发言，但不能屏蔽会议主持人和小组主持人的发言和文字信息。3.1.4 两人秘密语音通话会议的参加者可以进行两人秘密语音通话。此功能不影响会议其他人员语音发言。两人秘密语音通话由一方向另一方提出申请，当另一方接受后即可进行。两人秘密语音通话使用点对点通信。3.1.5 系统日志功能记录系统运行信息、客户访问信息、非法请求和非法尝试等。系统运行信息包括：系统启动时间和系统停止时间。客户访问信息包括：用户登录的时间、IP地址；用户离开系统的时间。非法请求：当系统发现有不合法的连接时，将记录此不合法连接的时间、IP地址。以便管理员发现和预防安全攻击。非法尝试：任何错误的用户名、密码以及管理员密码的尝试都会被视为非法尝试而记录在案。3.1.6 基于Web的系统管理功能系统提供了基于Web的系统管理界面。目前，系统提供的管理功能包括：创建公共会议；关闭公共会议；强行使某个会议的参加者离开会议。同时系统为管理员提供了专门的数据库管理界面，可以直接对数据库中的表单数据进行修改。3.1.7 多种身份认证方式系统提供使用CGI和认证模块两种方式进行用户身份认证。如果使用CGI方式，可以使用PHP，PERL等各种流行的CGI开发工具。如果使用认证模块方式，需要使用系统提供的开发包。用户的信息可以存放在文件、数据库、目录服务中。3.1.9 创建私人会议系统提供用户建立私人会议功能。同时，提供额外的私人会议认证方式。3.2 网络底层技术3.2.1 网络基础，点对点通信) PPP：点对点协议P P P，点对点协议修改了S L I P协议中的所有缺陷。P P P包括以下三个部分：A. 在串行链路上封装I P数据报的方法。P P P既支持数据为8位和无奇偶检验的异步模式（如大多数计算机上都普遍存在的串行接口），还支持面向比特的同步链接。B. 建立、配置及测试数据链路的链路控制协议（ L C P：Link Control Protocol）。它允许通信双方进行协商，以确定不同的选项。C. 针对不同网络层协议的网络控制协议（ N C P：Network Control Protocol）体系。当前R F C定义的网络层有I P、O S I网络层、D E C n e t以及A p p l e Ta l k。例如，IP NCP允许双方商定是否对报文首部进行压缩，类似于C S L I P（缩写词N C P也可用在T C P的前面）。RFC 1548Simpson 1993描述了报文封装的方法和链路控制协议。RFC 1332McGregor1 9 9 2 描述了针对I P的网络控制协议。P P P数据帧的格式看上去很像I S O的H D L C（高层数据链路控制）标准。每一帧都以标志字符0 x 7 e开始和结束。紧接着是一个地址字节，值始终是0 x ff，然后是一个值为0 x 0 3的控制字节。接下来是协议字段，类似于以太网中类型字段的功能。当它的值为0 x 0 0 2 1时，表示信息字段是一个I P数据报；值为0 x c 0 2 1时，表示信息字段是链路控制数据；值为0 x 8 0 2 1时，表示信息字段是网络控制数据。C R C字段（或F C S，帧检验序列）是一个循环冗余检验码，以检测数据帧中的错误。由于标志字符的值是0 x 7 e，因此当该字符出现在信息字段中时， P P P需要对它进行转义。在同步链路中，该过程是通过一种称作比特填充(bit stuff i n g )的硬件技术来完成的 Ta n e n b a u m1 9 8 9 。在异步链路中，特殊字符0 x 7 d用作转义字符。当它出现在P P P数据帧中时，那么紧接着的字符的第6个比特要取其补码，具体实现过程如下：a. 当遇到字符0 x 7 e时，需连续传送两个字符： 0 x 7 d和0 x 5 e，以实现标志字符的转义。b. 当遇到转义字符0 x 7 d时，需连续传送两个字符： 0 x 7 d和0 x 5 d，以实现转义字符的转义。c 默认情况下，如果字符的值小于0 x 2 0（比如，一个A S C I I控制字符），一般都要进行转义。例如，遇到字符0 x 0 1时需连续传送0 x 7 d和0 x 2 1两个字符（这时，第6个比特取补码后变为1，而前面两种情况均把它变为0）。这样做的原因是防止它们出现在双方主机的串行接口驱动程序或调制解调器中，因为有时它们会把这些控制字符解释成特殊的含义。另一种可能是用链路控制协议来指定是否需要对这3 2个字符中的某一些值进行转义。默认情况下是对所有的3 2个字符都进行转义。与S L I P类似，由于P P P经常用于低速的串行链路，因此减少每一帧的字节数可以降低应用程序的交互时延。利用链路控制协议，大多数的产品通过协商可以省略标志符和地址字段，并且把协议字段由2个字节减少到1个字节。如果我们把P P P的帧格式与S L I P的帧格式进行比较会发现， P P P只增加了3个额外的字节： 1个字节留给协议字段，另2个给C R C字段使用。另外，使用I P网络控制协议，大多数的产品可以通过协商采用Van Jacobson报文首部压缩方法（对应于C S L I P压缩），减小I P和T C P首部长度。总的来说， P P P比S L I P具有下面这些优点：a. PPP支持在单根串行线路上运行多种协议，不只是I P协议；b. 每一帧都有循环冗余检验； c. 通信双方可以进行I P地址的动态协商(使用I P网络控制协议)； d. 与C S L I P类似，对T C P和I P报文首部进行压缩； e. 链路控制协议可以对多个数据链路选项进行设置。为这些优点付出的代价是在每一帧的首部增加3个字节，当建立链路时要发送几帧协商数据，以及更为复杂的实现。) UDP：用户数据报协议U D P是一个简单的面向数据报的运输层协议：进程的每个输出操作都正好产生一个U D P数据报，并组装成一份待发送的I P数据报。这与面向流字符的协议不同，如T C P，应用程序产生的全体数据与真正发送的单个I P数据报可能没有什么联系。U D P数据报封装成一份I P数据报的格式RFC 768 Postel 1980 是U D P的正式规范。U D P不提供可靠性：它把应用程序传给I P层的数据发送出去，但是并不保证它们能到达目的地。应用程序必须关心I P数据报的长度。如果它超过网络的M T U，那么就要对I P数据报进行分片。如果需要，源端到目的端之间的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。(.1) UDP首部端口号表示发送进程和接收进程。在图1 - 8中，我们画出了T C P和U D P用目的端口号来分用来自I P层的数据的过程。由于I P层已经把I P数据报分配给T C P或U D P（根据I P首部中协议字段值），因此T C P端口号由T C P来查看，而U D P端口号由U D P来查看。T C P端口号与U D P端口号是相互独立的。16位源端口号 16位目的端口号16位UDP长度 16位UDP检验和数据(如果有)尽管相互独立，如果T C P和U D P同时提供某种知名服务，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本身的要求。U D P长度字段指的是U D P首部和U D P数据的字节长度。该字段的最小值为8字节（发送一份0字节的U D P数据报是O K）。这个U D P长度是有冗余的。I P数据报长度指的是数据报全长，因此U D P数据报长度是全长减去I P首部的长度（该值在首部长度字段中指定）。(.2) UDP校验和U D P检验和覆盖U D P首部和U D P数据。回想I P首部的检验和，它只覆盖I P的首部并不覆盖I P数据报中的任何数据。U D P和T C P在首部中都有覆盖它们首部和数据的检验和。U D P的检验和是可选的，而T C P的检验和是必需的。尽管U D P检验和的基本计算方法与我们在3 . 2节中描述的I P首部检验和计算方法相类似（16 bit字的二进制反码和），但是它们之间存在不同的地方。首先， U D P数据报的长度可以为奇数字节，但是检验和算法是把若干个16 bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。其次， U D P数据报和T C P段都包含一个1 2字节长的伪首部，它是为了计算检验和而设置的。伪首部包含I P首部一些字段。其目的是让U D P两次检查数据是否已经正确到达目的地（例如， I P没有接受地址不是本主机的数据报，以及I P没有把应传给另一高层的数据报传给U D P）。(.3) 最大UDP数据报长度理论上，I P数据报的最大长度是6 5 5 3 5字节，这是由I P首部1 6比特总长度字段所限制的。去除2 0字节的I P首部和8个字节的U D P首部， U D P数据报中用户数据的最长长度为6 5 5 0 7字节。但是，大多数实现所提供的长度比这个最大值小。我们将遇到两个限制因素。第一，应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大U D P数据报的长度直接相关。现在的大部分系统都默认提供了可读写大于8 1 9 2字节的U D P数据报（使用这个默认值是因为8 1 9 2是N F S读写用户数据数的默认值）。第二个限制来自于T C P / I P的内核实现。可能存在一些实现特性（或差错），使I P数据报长度小于6 5 5 3 5字节。作者使用s o c k程序对不同U D P数据报长度进行了试验。在SunOS 4.1.3下使用环回接口的最大I P数据报长度是3 2 7 6 7字节。比它大的值都会发生差错。但是从B S D / 3 8 6到SunOS 4.1.3的情况下，S u n所能接收到最大I P数据报长度为3 2 7 8 6字节（即3 2 7 5 8字节用户数据）。在Solaris 2.2下使用环回接口，最大可收发I P数据报长度为6 5 5 3 5字节。从Solaris 2.2到AIX 3.2.2，发送的最大IP数据报长度可以是65535字节。很显然，这个限制与源端和目的端的实现有关。要求主机必须能够接收最短为5 7 6字节的I P数据报。在许多U D P应用程序的设计中，其应用程序数据被限制成5 1 2字节或更小，因此比这个限制值小。例如，路径信息协议总是发送每份数据报小于5 1 2字节的数据。在其他U D P应用程序如D N S、T F T P、B O O T P以及S N M P中也会遇到这个限制。(.4) 数据报截断由于I P能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据。因此， U D P编程接口允许应用程序指定每次返回的最大字节数。如果接收到的数据报长度大于应用程序所能处理的长度，那么结果取决于编程接口和实现。典型的B e r k e l e y版socket API对数据报进行截断，并丢弃任何多余的数据。应用程序何时能够知道，则与版本有关（4.3BSD Reno及其后的版本可以通知应用程序数据报被截断）。S V R 4下的socket API(包括Solaris 2.x) 并不截断数据报。超出部分数据在后面的读取中返回。它也不通知应用程序从单个UDP数据报中多次进行读取操作。TLI API不丢弃数据。相反，它返回一个标志表明可以获得更多的数据，而应用程序后面的读操作将返回数据报的其余部分。T C P为应用程序提供连续的字节流，而没有任何信息边界。T C P以应用程序读操作时所要求的长度来传送数据，因此，在这个接口下，不会发生数据丢失。(.5) UDP服务器的设计使用U D P的一些蕴含对于设计和实现服务器会产生影响。通常，客户端的设计和实现比服务器端的要容易一些，典型的服务器与操作系统进行交互作用，而且大多数需要同时处理多个客户。通常一个客户启动后直接与单个服务器通信，然后就结束了。而对于服务器来说，它启动后处于休眠状态，等待客户请求的到来。对于U D P来说，当客户数据报到达时，服务器苏醒过来，数据报中可能包含来自客户的某种形式的请求消息。在这里我们所感兴趣的并不是客户和服务器的编程方面（ Stevens 1990对这些方面的细节进行了讨论），而是U D P那些影响使用该协议的服务器的设计和实现方面的协议特性。尽管所描述的一些特性取决于所使用U D P的实现，但对于大多数实现来说，这些特性是公共的。(.6) 客户IP地址及端口号来自客户的是U D P数据报。I P首部包含源端和目的端I P地址， U D P首部包含了源端和目的端的U D P端口号。当一个应用程序接收到U D P数据报时，操作系统必须告诉它是谁发送了这份消息，即源I P地址和端口号。这个特性允许一个交互U D P服务器对多个客户进行处理。给每个发送请求的客户发回应(.7) 目的IP地址一些应用程序需要知道数据报是发送给谁的，即目的I P地址。例如， Host RequirementsR F C规定，T F T P服务器必须忽略接收到的发往广播地址的数据报。这要求操作系统从接收到的U D P数据报中将目的I P地址交给应用程序。但是，并非所有的实现都提供这个功能。3.2.2 广播I P地址有三种：单播地址、广播地址和多播地址。广播和多播仅应用于U D P，它们对需将报文同时传往多个接收者的应用来说十分重要。T C P是一个面向连接的协议，它意味着分别运行于两主机（由I P地址确定）内的两进程（由端口号确定）间存在一条连接。考虑包含多个主机的共享信道网络如以太网。每个以太网帧包含源主机和目的主机的以太网地址（4 8 b i t）。通常每个以太网帧仅发往单个目的主机，目的地址指明单个接收接口，因而称为单播( u n i c a s t )。在这种方式下，任意两个主机的通信不会干扰网内其他主机（可能引起争夺共享信道的情况除外）。然而，有时一个主机要向网上的所有其他主机发送帧，这就是广播。通过A R P和R A R P可以看到这一过程。多播(multicast) 处于单播和广播之间：帧仅传送给属于多播组的多个主机。为了弄清广播和多播，需要了解主机对由信道传送过来帧的过滤过程。首先，网卡查看由信道传送过来的帧，确定是否接收该帧，若接收后就将它传往设备驱动程序。通常网卡仅接收那些目的地址为网卡物理地址或广播地址的帧。另外，多数接口均被设置为混合模式，这种模式能接收每个帧的一个复制。作为一个例子， t c p d u m p使用这种模式。目前，大多数的网卡经过配置都能接收目的地址为多播地址或某些子网多播地址的帧。对于以太网，当地址中最高字节的最低位设置为1时表示该地址是一个多播地址，用十六进制可表示为0 1 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0（以太网广播地址ff : ff : ff : ff : ff : ff可看作是以太网多播地址的特例）。如果网卡收到一个帧，这个帧将被传送给设备驱动程序（如果帧检验和错，网卡将丢弃该帧）。设备驱动程序将进行另外的帧过滤。首先，帧类型中必须指定要使用的协议（ I P、A R P等等）。其次，进行多播过滤来检测该主机是否属于多播地址说明的多播组。设备驱动程序随后将数据帧传送给下一层，比如，当帧类型指定为I P数据报时，就传往I P层。I P根据I P地址中的源地址和目的地址进行更多的过滤检测。如果正常，就将数据报传送给下一层（如T C P或U D P）。每次U D P收到由I P传送来的数据报，就根据目的端口号，有时还有源端口号进行数据。广播I P广播地址分为四种，下面对它们进行更详细的介绍。) 受限的广播受限的广播地址是2 5 5 . 2 5 5 . 2 5 5 . 2 5 5。该地址用于主机配置过程中I P数据报的目的地址，此时，主机可能还不知道它所在网络的网络掩码，甚至连它的I P地址也不知道。在任何情况下，路由器都不转发目的地址为受限的广播地址的数据报，这样的数据报仅出现在本地网络中。一个未解的问题是：如果一个主机是多接口的，当一个进程向本网广播地址发送数据报时，为实现广播，是否应该将数据报发送到每个相连的接口上？如果不是这样，想对主机所有接口广播的应用必须确定主机中支持广播的所有接口，然后向每个接口发送一个数据报复制。大多数B S D系统将2 5 5 . 2 5 5 . 2 5 5 . 2 5 5看作是配置后第一个接口的广播地址，并且不提供向所属具备广播能力的接口传送数据报的功能。不过， r o u t e d和r w h o d（B S Dr w h o客户的服务器）是向每个接口发送U D P数据报的两个应用程序。这两个应用程序均用相似的启动过程来确定主机中的所有接口，并了解哪些接口具备广播能力。同时，将对应于那种接口的指向网络的广播地址作为发往该接口的数据报的目的地址。Host Requirements RFC没有进一步涉及多接口主机是否应当向其所有的接口发送受限的广播。) 指向网络的广播指向网络的广播地址是主机号为全1的地址。A类网络广播地址为n e t i d . 2 5 5 . 2 5 5 . 2 5 5，其中n e t i d为A类网络的网络号。一个路由器必须转发指向网络的广播，但它也必须有一个不进行转发的选择。) 指向子网的广播指向子网的广播地址为主机号为全1且有特定子网号的地址。作为子网直接广播地址的I P地址需要了解子网的掩码。例如，如果路由器收到发往1 2 8 . 1 . 2 . 2 5 5的数据报，当B类网1 2 8 . 1的子网掩码为2 5 5 . 2 5 5 . 2 5 5 . 0时，该地址就是指向子网的广播地址；但如果该子网的掩码为2 5 5 . 2 5 5 . 2 5 4 . 0，该地址就不是指向子网的广播地址。) 指向所有子网的广播指向所有子网的广播也需要了解目的网络的子网掩码，以便与指向网络的广播地址区分开。指向所有子网的广播地址的子网号及主机号为全1。例如，如果目的子网掩码为2 5 5 . 2 5 5 . 2 5 5 . 0，那么I P地址1 2 8 . 1 . 2 5 5 . 2 5 5是一个指向所有子网的广播地址。然而，如果网络没有划分子网，这就是一个指向网络的广播。当前的看法Almquist 1993是这种广播是陈旧过时的，更好的方式是使用多播而不是对所有子网的广播。Almquist 1993 指出RFC 922要求将一个指向所有子网的广播传送给所有子网，但当前的路由器没有这么做。这很幸运，因为一个因错误配置而没有子网掩码的主机会把它的本地广播传送到所有子网。例如，如果I P地址为1 2 8 . 1 . 2 . 3的主机没有设置子网掩码，它的广播地址在正常情况下的默认值是1 2 8 . 1 . 2 5 5 . 2 5 5。但如果子网掩码被设置为，那么由错误配置的主机发出的广播将指向所有的子网。1 9 8 3年问世的4 . 2 B S D是第一个影响广泛的T C P / I P的实现，它使用主机号全0作为广播地址。一个最早提到广播IP地址的是IEN 212 Gurwitz and Hinden 1982，它提出用主机号中的1比特来表示I P广播地址（ IENs 是互联网试验注释，基本上是R F C的前身）。RFC 894 Hornig 1984认为4.2BSD使用不标准的广播地址，但RFC 906 Finlayson 1984注意到对广播地址还没有I n t e r n e t标准。R F C编辑在RFC 906中加了一个脚注承认缺少标准的广播地址，并强烈推荐将主机号全1作为广播地址。尽管1 9 8 6年的4 . 3 B S D采用主机号全1表示广播地址，但直到9 0年代早期，操作系统（著名的是SunOS 4.x）还继续使用非标准的广播地址。3.3 本系统中用到的语音编解码规范音频的编解码，压缩转换音频编解码使用g.729协议G.729建议使用CS-ACELP的8kb/s话音编码算法，其编译码原理如下。3.3.1 编码原理模拟输入信号经话带滤波后以8000Hz取样率采样，获得的样值随后转换为16比特线性PCM信号并输入到编码器。编码器在10ms的话音帧上运行，它相应于采样速率每秒8000次的80个样本。对每个10ms帧而言，分析话音信号以抽取码激励线性预测(CELP)模式的参数。在预处理单元中，输入信号须经过定标和高通滤波。定标是指输入信号被2除，以降低定点运算中的溢出可能；高通滤波则滤掉不希望出现的低频分量。经预处理的信号充当所有后续分析使用的输入信号。LP分析每10ms帧进行一次，以计算LP滤波器系数，此后，为了量化与内插的目的，将该LP系数转换到线谱对(LSP)域，接着把内插的量化的与非量化的滤波器转换回LP滤波系数，以构造每子帧的合成与加权滤波器。每10ms帧根据感知加权话音信号估计一次开环基音延迟，然后对各子帧重复以下运算：A. 滤波器的初始态通过LPC信息与激励间的误差滤波来更新；B. 通过LPC信息经由加权合成滤波器的滤波来计算目标信号x(n)；C. 计算加权合成滤波器的脉冲响应h(n)；D. 通过开环基音延迟值的搜寻，使用目标信号x(n)和脉冲响应h(n)来完成闭环基音分析，以发现自适应码本的延迟与增益；E. 通过除去自适应码本影响，更新目标信号x(n)，并且所产生的新的目标信号x(n)用于在固定码本中搜寻发现最佳激励；F. 自适应与固定码本产生的增益采用7比特矢量量化，通过极小化原始话音与重构话音间的均方加权误差完成增益码本的搜寻；G. 使用决定的激励信号对合成与加权滤波器的状态更新以计算下一子帧的目标信号。这样，完成CS-ACELP的编码过程，编码出传输速率为8kb/s的话音信号比特流(而普通的PCM话音为64kb/s)。3.1.2 译码原理首先，从接收到的比特流中抽取参数的指标，译码后获取相应于10ms话音帧的编码参数。这些参数为LSP系数、两个分数基音延迟、两个固定码本矢量以及自适应码本增益与固定码本增益的两个集。对每个子帧内插LSP系数并将其转换为LP滤波器系数。然后，对于每个5ms子帧实施以下步骤：分别按其增益进行定标的自适应码本矢量相加与固定码本矢量，构造激励；通过LP合成滤波器滤波上述激励，重构话音；重构话音信号经后置处理后还原出普通的PCM(64kb/s)话音信号。此外，VG还执行话音通道互连功能，即IP网中传输话音时，是通过实时传输协议(RTP)来传送的，而PSTN则通过B通道。附：G729与G7223.1以及G729A的性能对比 编码方法 G.723.1 G.729 G.729A 比特率 5.3/6.3kb/s 8kb/s 8kb/s 帧长度 30ms 10ms 10ms 处理时延 30ms 10ms 10ms 观看时延 7.5ms 5ms 5ms 帧字节数 20/24 10 10 DSP MIP 16 20 10.5 RAM 2200 3000 2000G.729原来是8kb/s的话音编码标准，现在经进一步的研究和实践将其工作范围扩展至6.411.8kb/s，话音质量也在此范围内有一定的变化，但即使是6.4kb/s，话音质量也还不错，因而很适合在VoIP系统中使用。G723.1采用5.3/6.3kb/s双速率话音编码，其话音质量好，但是处理时延较大，它是目前已标准化的最低速率的话音编码算法。在目前接入网速度普遍较低的情况下，G.723.1话音编码也大量运用于H.323会议系统中。3.4 数据库设计数据库设计概述数据库设计就是针对应用需求和环境，建立合理的数据库模式和存储结构，保证数据的高效存取，并满足应用的任务处理要求。数据库设计是应用系统建设的核心技术，是数据库应用领域的主要研究课题。3.4.1 数据库设计的任务A. 建立面向数据存储的模式（表、序列、同义词、索引、集聚、数据库链等）设计物理存储结构（表空间、数据块、范围、段；数据文件、日志文件、控制文件）B. 设计面向任务处理的模式（包、存储过程、函数、触发器、视图等）C. 面向数据存储、任务处理和环境调整数据库设计（模式和存储结构）3.4.2 数据库设计应考虑的因素) 数据库的大小（内存和外存）A. SQL支持超大型数据库（数据文件32GB、表空间数据文件数1022、表空间32TB）B. 启动数据库实例所需的内存C. 数据库（文件）所需的磁盘空间D. 文件装入所需的临时空间（内存和外存）E. 数据库的发展) 性能A. 磁盘I/O是引起性能瓶颈的主要因素（7200转/秒SCSI：连续I/O为100个/驱动器；随机I/O为60-70个/驱动器）B. 隔离连续存取的数据（重做日志文件和存档日志文件）C. 分布随机存取的数据（多磁盘或RAID，因性能增加的磁盘驱动器比因空间增加的多）D. 增加内存（并行I/O）E. 设置缓存（减少I/O）) 功能A. 数据库分割为多个表空间，便于备份和恢复B. 模式设计与处理任务（任务分解与面向任务处理的模式）C. 内码设计与功能实现（编程与运行效率）D. 应用类型与存储结构（OLTP与DSS对日志存放要求不同）) 数据保护A. 重做日志文件和存档日志文件需要完整保护B. 软件故障容错使用少，硬件故障容错使用多（RAID1和RAID5）RAID1（Mirroring）提供最快的故障容错和最大的保护，需要双倍磁盘（空间）（OS和日志文件）RAID5（Data Guarding）跨磁盘写入奇偶校验信息，可避免一个磁盘故障，读最快，写最慢（数据文件）) 分区A. 表可以根据数据的范围分区D. 分区在表空间级实现，表空间由数据文件组成（建立数据文件之前规划分区）SQL2000支持范围分区、哈西分区、组合分区，分区在提高性能方面有明显作用) 字符集A. 建立数据库前要选择字符集B. 不重建数据库就不允许修改字符集C. 客户端字符集应该与数据库字符集相同或是其子集3.4.3 数据库设计中的原则) 实体、属性和关系A. 实体是数据模型中存储信息的对象，用户工作环境中可标识出的事物或业务元素。实体可以是具体的对象、抽象的概念、虚幻的东西等；实体是现实世界中具有相同性质的一类事物，实例是实体的具体例子；实体的每个实例都必须可以唯一标识；每个实体之间都是互斥的；B. 属性是描述实体的状态与特征的指标。属性包括强制属性和可选属性C. 关系是实体之间有意义的关联。关系包括强制关系和可选关系一对一、一对多、多对多、依赖、递归、分类、排斥) 对象命名规范表名和列名最大长度为30个字符；忽略表名和列名的大小写，以大写形式将表名和列名存储在数据字典中；用大写存储数据比较容易（*）；A. 命名有意义B. 层次命名完整性（域名.数据库实例名.所有者.对象名.字段名）C. 采用英文（避免用拼音*）D. 单数形式E. 简洁又清晰（短词、缩写词、自定义缩写词）F. 一致性（不同表中属性名一致性、一致使用或不使用下划线、一致使用首字母大写）G. 分类性（密切相关的一组属性采用同一的前缀）H 别名不要加（双）引号I. 建立对象名称词典（不同于数据库内部的数据字典）) 规范化及设计范式规范化是把有问题的关系转化为没有问题的关系的过程，设计要求规范化，但规范化不是设计。规范化应该在物理层进行，但在概念和逻辑层也可以使用。规范化的主要目的有三个：A. 保持数据完整性B. 建立尽可能与应用无关的模型（关系模型应该是数据驱动的，而不是程序驱动的，即改变处理需求时数据库结构能保持稳定；应用程序的要求应该与数据库的逻辑设计无关，但应用程序功能要求对数据库物理设计很有意义）C. 减少存储需求（消除或减少冗余、搜索数据少可能提高性能）范式要 求1NF“当且仅当所有的基础域仅包含原子值”。所有属性的数据为不可分的数据项，即某个属性不能同时有多个值或不能有重复的值，同一属性的所有记录值为同一类型、单值（与唯一值不同），任意两个记录不能完全相同（即关键字确定其它属性）。规范化措施：分解同时具有多个值的属性，去掉重复的属性。2NF“当且仅当满足1NF，且所有非关键字属性都依赖于整个主关键字”。主关键字有单个属性关键字或多个属性组合关键字。规范化措施：分离仅依赖部分主关键字的属性构成新实体，与原实体建立一对多的关系。3NF“当且仅当满足2NF，且所有非关键字属性都是非传递地依赖主关键字”。传递依赖指实体中存在依赖其它非关键字属性的属性。规范化措施：分离依赖其它非关键字属性的属性构成新实体，新实体的关键字属性就是原实体中被依赖的属性。BCNF“当且仅当所有的决定因素都是侯选关键字”。两个或多个可作为关键字的属性或属性组合称作侯选关键字，任意一个选作关键字的后选关键字称作主关键字。规范化措施：分离出新实体，使每个实体的决定因素都是后选关键字。4NF“当且仅当满足BCNF，且没有多值依赖”。5NF依赖关系模糊，有关分解为自关系的关系要求。（参考）不规范化存在的共同问题：插入异常、删除异常、数据冗余修改复杂。3.4.4 SQL2000简介鉴于MicroSoft VisualStudio.Net直接提供了对SQL2000的支持，故本系统选用SQL Sever2000标准版。) SQL简介SQL Sever起始于Sybase SQL Sever。MicroSoft SQL Sever 2000 扩展了MicroSoft SQL Sever7.0 版的性能、可靠性、质量和易用性。SQL Sever200增加了几种新的功能，由此成为大规模联机事务处理（OLTP）、数据仓库和电子商务应用程序的优秀数据库平台。在SQL Sever2000中，增强的内容主要是针对易用性、可伸缩性和数据仓库。SQL Sever2000在两个方面有了很大的变化。一是基本内容的变化，例如在核心的数据库引擎方面。二是外观的变化，例如在用户界面和管理实用程序方面。SQL2000标准版作为小工作组或部门的数据库服务器实用，适合本会议系统对于数据库的要求。(.1)SQL2000的性能SQL2000数据库引擎提供完整的XML支持。它具有构成最大的Web站点的数据存储组件所需的可伸缩性、可用性和安全功能。SQL Server2000程序设计模型与Windows DNA构架集成，用以开发Web应用程序，并且SQL2000支持English Query和Microsoft搜索服务等功能，在Web应用程序中包含了用户友好的查询和强大的搜索功能。Microsoft SQL Server 2000包含多个支持大型Web站点和时下的企业数据处理系统的复杂数据存储需求的功能。SQL Server 2000分布式查询使用户得以引用来自不同数据源的数据，就好像这些数据是SQL Server2000数据库的一部分，同时分布式事务支持充分保护任何分布式数据更新的完整性。SQL Server2000复制使用户得以在多个站点使用发布订阅术语维护数据的复本。(.2)SQL2000的安全用户标识和鉴别是系统提供的最外层安全保护措施。其方法是由系统提供一定的方式让用户标识自己的名字或身份。每次用户要求进入系统时，由系统进行核对，通过鉴定后才提供机器使用权。例如，使用用户名和口令。数据库安全性所关心的主要是DBMS的存取控制机制。数据库安全最重要的一点就是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，这主要通过数据库系统的存取控制机制实现。 存取控制机制主要包括两部分： A. 定义用户权限，并将用户权限登记到数据字典中。 B. 合法权限检查，每当用户发出存取数据库的操作请求后（请求一般应包括操 作类型、操作对象和操作用户等信息），DBMS查找数据字典，根据安全规则进行合法权限检查，若用户的操作请求超出了定义的权限，系统将拒绝执行此操作。大型数据库管理系统几乎都支持自主存取控制，目前的SQL标准也对自主存取控制提供支持，这主要通