（计算机应用技术专业论文）媒体服务器的资源管理.pdf

琵衷郎毫大学磺士攀整论文媒俸瓣务器熬蝥潺繁毽 摘要 本人毕业论文的主要内容是媒体服务器的资源管理。在媒体服务器的研发过程中所阁到 懿疆转主要有骚警王拯极、s u n 工作站、n m s 蔽卡帮s a n h u i d 扳卡，软 牛琢境是s c o u n i x w a r e7 ，1 1 、w i n d o w s 孵操终系统，采糟了v i s u a le + + 帮豁难e + 作为较馋殍发语害。 媒体服务器能蟛为用户提供多种多样，丰富多彩的服务。现阶段，媒体服务器能够为蘩 个应用系统提供交甄式语音应答( i v r ) 、电话会议、传真消息、d t m f 音频处理、自动语音 识别( a s r ) 、文本到语音转换( t t s ) 、阉网短消息等多种功能。以后根据实际需要，述可 以增加语音信箱、视频会议、视频点播、统一消息、屯子邮件等功能。用户能够方便地通 过多种方式接入系统并快速获取所需绉患。 媒体骚务器受豢疯层各赞资滚熬统一潺凌帮管理，对上层戆斑耀瀑菠了具蒋豹实瑰缳节， 箍佬了各种韭务的湃发过程帮业务逻辑瓣执行过程。必须有效建缀织好媒体服务器中驰各种 资源，使它们能够中高效，可靠地运作而又彼此不会产生干扰。 我们采用面向对象的思想，对媒体服务器进行分层设计，馒其包括资源管理层、服务层、 控制层3 个层次。 同时，为了提黼蓉统运行效率，采用了多线程技术。使用多线程技术能有效地帮助实现 瘦耀程痔具有更裹憾箍释更佳赛静可 孛缀燃。 关键词：媒体服务器控制节点( c n ) 资源节点( r n ) 资源管理层( m a n a g e m e n tl a y e r ) 服务层( s e r v i c el a y e r )资源控制层( c o n t r o ll a y e r )线程池( t h r e a dp 0 0 1 ) 语音识别( a s r )文本转语音( t t s ) 交互式语音应答( i v r ) 套结字( s o c k e t ) 有名营道( f i f o ) 共享内存( s h a r e dm e m o r y ) 进程间通信( i p c ) 2 惩哀簿毫大学硬士学位论文媒俸疆务嚣静资灞蟹毽 1 。1 背景 第一章前言 。 。 攥薅疆努器筑奔 随着电子信息技术的不断发展，人类穗进入了信息时代。夜储患时代+ 大忭】对信息需求 嫩与日剧增，并不断搬出新的更高的要求，相对而言传统的通信方域已不再满足于当前社会 信息量的需求。目前，电话是人们交流信息的个重要方式，也是获取外界信息的主要避张 之一，但对于电话用户而言，这种交流方溅具有一定的限制，比较单调，缺乏主动性和随意 性。数磊，亟霉建立瓣巽骞主动控、髓豢性，能够窭霹提供多媒体鼹努戆业务系统，鲻户 可虢通过该系统蠡主选择，蘧霹获取蠢鬏、视叛等多攥律蕊惠黻努。 媒体鞭务器就在这种背景下痤运嚣空。嫌俘服务器能够为用户提供多种多撵，丰富多彩 的服务。现阶段，媒体服务器能够为整个成用系统提供交互式语诲威答( i v r ) 、电话会议、 传真、d t m f 音频处理、自动语音识别( a s r ) 、文本到语音转换( t f s ) 、固网短消息锱寥 种功能。以后根据蜜际需要，我们还可以增加语音信箱、视频会议、视频点播、统一消息、 逛子部件等功能；造成道信潮不新融合的发鼹趋势，依托综合产晶技术，提供集成疆鸯、 俦奏、p 、w e b 、e - m a i l 、藕颧等多耱攥髂接入鳆全委磐凌方案，挺舞禹尹综台竞争力。 鬻户糍够灵活地逶过多种方式接a 并获敷掰震要翡蕊惠，飙纛挺窿雳户静清意度。 1 1 2 媒体服务器柱糟能网中的应用 智能网是通过分开以往集中在电话变换礤统内完成的交换接续功能和业务控制功能简 形成的一种新型网络服务。智能网能快速掇供多种业务，并具有溅滔、高效、稳定、省时、 保密等逮多优点。 磐麓露不是魏立存在鳆霹，是叠蟊京奄话交接两装。智蕤褥帮交接瓣荣靠叠共蕊遴溢 令系统密切联系在起。 智能网是以计辣机和数据库为核心静。它的主要组成部分有： 业务交换点( s s p ) 它是用户进入智能网的接入点，它悬个交换机，用来识别用 户对智能网的呼叫，把用户的请求传送给业务控制点。 业务控制点( s c p ) 是智能网的中心，通常是由大、中型计算机和大型数据库组成， 寇艘鑫嚣智麓监务翦实骢。它接受s s p 送采的信患，自鼗据疼蹙滋并离s s p 发窭煲强麓端 令。 智能卦设( 1 p i n t d l i g e n tp e r i p h e r y ) 楚磐能弱中重要酶功髓实体之一，完成特豫瓷源 功能( s r f ，s p e c i a lr e s o u r c ef u n c t i o n ) 。 此外，还有“倍令转换点”、“业务管理祭统”等，共同构成一个完挺的网络体系。 在智栽网中，媒体服务嚣侮为智能外没中抟资鞭节点为整个锻熊弼提供一拿资源支撑鬣 统。它为蓉麓潮褥供的特爨资源毽话： 瑕音多颧数字藏投： 信号音的发送； 语音通知； 白动语音合成； 自动语音合成： 熬寨鄄窀丈学疆圭学饿论文媒髂鞭务器戆费嚣薰壤 自动语音合成； 文本一一语音转换 人工座席； 信息存储转发； 1 1 3 媒薅骧务器在孬编程交换辊孛熬瘟弱 随着p 、移动撤务的急刷发震。遥傣终端的不断智雏佬，鲡何在融合不同的通信阚 ( p s t n 、i n t e m e t 和移动网) 的同时提高它们的利用率，、为用户掇供各种个性化的业务以满 足市场的新需求成为电信业发展的当务之急。 下一代业务的目标就是把业务应用移到随络运营范围之外，向独立的业务供应商开放市 场，同时为语音、多媒体和数据提供基于p 和移动方面的支持。逡就需要通信网具有标准 鲍、开藏静应用编程接弱( a p i ) ，健第三方娥务供应赢能够根据带场的需求设计出丰富多 彩躲电信韭务，这些熊务麓够逶过标准豹接瓣程逶售阐瘫部褥 冀实戮，谴瘸户充分享受黧璐 代道信所带来的舒适与方便。 可编程交换机系绫就支持这种标准的、开放的应用编程接口( a p i ) ，具有开放性，可 扩展性和伸缩性强等特点。可以快速、灵活、方便地开发新业务并投入使用，具有很强的市 场适应能力。 可编程交换机的蹰个定义性特点是：1 、访闽控制及交换。它按照特定访问模式下事俅 躲避辑j 羲序进行。2 、凌斑臻程序静控裁下设定访鞫模式。对予嚣款式、可编程交换枫，藏 耀程序驻餐在主梳内存中，逶过目答的命令方式控裁交换祝。 可编程交换机的生接任务是为公众网提供个多余度的接口，让主机管理网络访问的路 径、全部的交换和信号及媒体资源。 在可编程交换机中，媒体服务器是一个不可缺少的重要组成部分，为上层的应用服务器 提供了透明豹霹络资源，并为上层的业务开发提供了访阉底层各种多媒体资源的统一接秘， 罄菠了藏屡秘瑾资源麴麓菇牲，毒利予遭务熬歼发弱蠖瑶，毒力缝支持了系统驻努貔多元纯 和丰富性。 1 。2 论文内容 本论文包括以f 部分内容： 第二章简要介绍媒体服务器中资_ i 瓣管理和调度的分层设计模式。 4 2 第三章资源铃理模型的设计方案：洋细说明媒体服务器的各种资源调度和管理方 案；介缁了资源管理层、语音服务、信令服务、电话会议服务、o n 服务、 鳞囊嚣| 捌翅短售摄务熬设谤。 第疆章对t 糯s 帮s a n h u i d 投卡麓魄较萃嚣分毫蓐：对n m s 秘s a n h u i d 投专麓功麓、 特点作了一个简要的分析和比较。 附录对，媒体服务器的测试方案：简要说明了对r 整个系统的功能、性能方丽 的箨种指标的测试设计。 4 悲衷郄电大学颈士学位论文燕钵骚务器熬资源管壤 第二章资源管理模型概述 2 。1 资源节点概述 随着计冀辍处遴能力帮透信霹终数字纯躲避速发展，计箨瓿按米耱透信技术糖曩渗 透的进程明显加快，进而出现了计算机和通信阿的集成系统，速种集成是多层面、多角 度的，语音和传真的传送是c t i 应用的核心领域，发展极为迅速。与此同时，各种新业务 也不断诞生，如固网短消息、统一消息( u m s ) 等，从而增加了c t i 系统中资源管理和调度 的难度。如何有效珧组织好系统中的各种资源，使它们能够高效、可靠地运作而又彼此不 会产生干扰，是一个蠖褥关注静闫题。 媒傣缀务器瓣 # 胡缀重要窟受责瘾溪蔷耪资源戆统一调发釉骛瑾，对上层熬瘦强漭 蔽了具体的实残缎节，篱亿了各种业务的歼发过程稆业务逻辑静执行过程。 2 2 现有资源带点的设计方案分析 瑶黄，智能弛务节点中的资源节点的系统设计方案采蠲一秘蒜发集中熬管理帮i 辫躞 模式。下瑟戳该爨源节点系统惫铡避褥分耩。 2 2 1 智镌嫩务节点简介 首先，简要介绍一下智能业务节点。 从某种意义上来说，智能业务节点相当于一个小型的智能网。它具有强大的业务逻 辑控制功能，可以宪成语音处理、传真收发和3 0 0 电话卡等一系列业务豹加载和运行。 它将s c f 、s s f 、s d f 、s r f 、s m f 魂戆集中在一个节点巾。其薅系结擒如下： 驰” l i n a p 一s n 一厂一墨 s s 8 - i s u p1 “8 黜h a l i n g & 骶。- j 拳一 l 翻i 一誓蓄l 毒磊纛誊 蚓1 s n 系统结构幽 控制节点( c n ) 其中c n 是智能业务：捧点的控制j ，点，具有以f 功能： 北京邮电大学硕士学位论文媒体服务器的资源管理 能。 ( 1 ) 业务开发接口功能。c n 提供一系列完备的指令，方便业务开发者用来开发业务。 ( 2 ) 业务运行功能。c n 提供业务动态加载功能。开发完成的业务，通过命令可以在 系统中运行。 ( 3 ) 资源管理功能。c n 管理系统中所有的资源，包括业务实例的运行调度、时间同 步、硬件资源操作和硬件资源的增减。 ( 4 ) 计费功能、数据库管理功能、话务管理功能、统计功能以及与其它节点的通信功 资源节点( i c n ) i l n 为网络提供各种特殊资源它负责接收来自c n 的命令消息，调用相关的硬件资源 进行一系列的操作，然后将结果返回给上层控制节点，比如：录音、放音、收发传真等： 它负责对语音、传真、文语转换( t t s ) 、固网短消息和语音识别( a s r ) 等各种特殊资源 实施统一的调度和管理，屏蔽了底层硬件资源调用的复杂性，给上层提供一个简单、明确 的调用接口，从而极大地方便了业务的开发和执行。r n 和删之间的通信采用i n a p 协议 定义的消息。 管理节点小m p l n m p 负责对整个智能业务节点系统进行管理，它可以动态地获得系统运行的各种 信息，并向c n 发出请求，要求加载业务或者执行特定的操作。而且，n m p 和r n 之间也 有l a n 的连接，可以传送消息以控制r n 中的语音文件等信息。 智能业务节点具有强大的业务逻辑处理能力，以及灵活快速的组网方式，非常适用于 一些中小型的网络之中，可以大大降低运营商的成本，具有很好的性价比。 2 2 2 对智能业务节点中现有资源节点的分析 现有资源节点的系统结构如下图所示： 北京邮电大学硕士学位论文 媒体服务器的资源管理 图2 智能业务节点中资源节点( r n ) 的现行设计方案图 该系统位丁一个单独的物理节点上，由一个单独的进程来实现各种资源的调度和管 理功能。它是以功能为核心来进行系统定义和模块划分的：t n m p d r v 负责币in m p 管理 终端的通信，t a c c d r v 负责与a c c e s s 终端的通信，t c n d r v 负责与c n ( 即业务控制节点) 的通信。 该系统的核心思想是实现一个消息循环调度系统来驱动整个系统的运转，以轮洵的 方式来实现伪并发机制。 t f e a m 是一个管理类，负责对各个d r v 进行有效的管理。各个d r v 具有不同的处 理功能，有的d r v 具有对外的通信接口( 如t c n d r v ) ，而有的d r v 只是负责对一些消息 的处理f 如t r e s o u r c e m g r d r v ) ，无对外通信接口。对外通信接口分为f i f o 和s o c k e t 两种。 黥寒郄奄大学联圭学镦论文媛傣疆务纂懿姿源管壤 图3 t f e a m 系统结构图 当r n 收到柬自抖界的命令消息后，戴将其救入t f e a m 消息队列，再根据消息类别 蒋箕磐发绘不溺豹模块去处理。强暴楚n m p 终臻发来貔谬誊管理瀵惠，翔交绘 t p h o n e d r v 去处璎；船栗是c n 发亲戆裰卡操作消息，剽交给t r e s o u f c e m g r d r v 去处理，螽露 调度电话语音卡城其它的硬件资源来完成指定的操作，然后将邋回的结果放在t f e a m 里，待以后由t c n d r v 取出上报给c n 。 该系统将各种资源的调度权都交给了t r e s o u r c e m g r d r v 处理模块( 对语音文件的管 理例外，是由t p h o n e d r v 来实现的) 。这梯来，系统结构紧凑，管理榘中，条理清晰，能够稳 定毒效迪实现鄄定鲢操作，著及对返回络袋。在现有顼强的运萼j ：避狴中，经受往了大话势 量熬考验征骥该方寰是弼窭_ 莓孬瑟盈霉蠢藏效爨。 但是。随着备种新业务的投入使用，对于资源节点也提出了更黼的要求，它所管理和调 度的资源的种类和数量增多了，功能也将甄为复杂。按照以前的系统设计方案，每增加一 种新的资源，就必颁在t r e s o u r c e m g r d r v 中增加一个新的处理部分。从长远来看，这种功 能累加的方案难以满足日后系统扩容、业务增加的需要，势必造成系统结构臃肿、难以维 护的缺陷，根本原湖在于系统结构过于集中，不便于扩展。除此之外该系统中没有采用多 线程整理方式。实鼯上是一耱粪 娃予轮谗鹣调度方式，由于等待嬲络l o 事释帮叛舞i o 事 件静结束需要耗费相当的对惩，蕊鞋对予箨释事件静跫理效率较为低下，当话务量尉增融 系统的反应速度莉所减慢。 2 3 媒体服务器的优化设计方案 为了这裂缝搀合理、层次分臻、条疆渣糍、荔予扩容、便l ：维护帮提毫系绞运行效 率瓣譬懿。我们对该系统重新进行了设计。 2 3 1 将系统分为5 个层次： 关键是采川分层设计的思想，将可编槲交换机分为系统应川屡、资源管理层、服务 层、控制层和资渊偿五个层次对原米过1 二集中的系统进行了必臻的分离，以提高系统的 运行效率和可维护性。而媒体服务器包括了资源管理层、服务层、控制层雨1 资源层。 2 3 1 1a p p l i c a t i o nl a y e r ： 北京邮电大学硕士学位论文媒体服务器的资源管理 该层负责对用户的各种实际应用( 也就是各个业务实例) 提供一个统一的接口，在功 能上相当于原来的控制节点，动态生成各个业务实例的对象，并对它们进行统一的调度和 管理。该层与m a n a g e m e n t l a y e r 之间既可以使用p a r l e y 标准定义的a p i ，也可以采用s i p 消息进行通信。 2 3 1 2 m a n a g e m e n tl a y e r ： 该层负责管理底层的各种资源和服务实体的动态加载、删除和扩容等功能，并对应 用层提供统一的资源调度接口，屏蔽了底层各种资源的差异。它对于各种服务都有一个 相应的资源管理列表，当收到a p p l i c a t i o nl a y e r 发来的信息时，根据其业务实例，决定对该 信息如何编码，并用s o c k e t 发送给相关的各个服务对象去处理；可以实现对于各种服务的 统一调度管理，包括服务的动态加载和删除，查询各个服务的工作状态等。又如，根据现 有资源节点中的会议资源的数量来决定是否可以增加新的会议或者为某个会议加入一 个新的成员等。 2 3 1 3 s e r v i c el a y e r ： 该层是由各个服务对象组成的服务层，负责对上提供各种应用服务的内部消息接口， 如传真、语音，交换和固网短消息等，对下控制各个服务的执行过程。该层从上面收到 请求服务的消息后，将其再次划分为若干部分，交给c o n t r o ll a y e r 层的处理模块去处理。 比如，上面发来一个p c 消息( i n a p 协议定义的完成放音和收号操作的消息) ，则s e r v i c e l a y e r 将其注册后，把该消息拆分为放音、收号两个原子操作，归入相应的状态链表，然后 再向下层的放音模块发送放音的原子消息，控制完成放音操作，收到电话语音板卡上报的 正确返回事件后，再向下发送收号的原子消息，控制电话语音卡完成收号操作。该层中的 务懋溅务瓣象露鼷畿秘藏鹪黪理节点，提商了系统的霹扩攫憔和可维护性。由于控制 层中暂时不用的原子操作调用接口都是以动态链接库的形式存在的，当系统中需要添加 某种服务时，我们只需要在s e r v i c el a y e r 层中启动相应的服务、与资源管理层和控制 层建立通信连接即可。 2 3 1 4c o n t r o ll a y e r 该层负责完成对于各种物理资源( 如电话语音卡) 和软件资源( 如语音文件表) 的直接 管理和调度。这部分根据c o n t r o ll a y e r 发来的原子消息，执行最基本的单元操作，比 如放音操作，它调用相应类型的语音板卡的a p i ，执行放音操作后，再将语音板卡返回的事 件上报给c o n t r o ll a y e r 。该层屏蔽了底层资源的一些细节，对上提供相对统一的原子操 作调用接口，如对于放音操作，s e r v i c el a y e r 只是发送通用的放音消息下来，而c o n t r o l l a y e r 收到后根据消息中指定的资源编号，查看是n m s 还是s a n h u i d 的板卡，再调用相应 的电话语音卡的放音操作函数。这些函数可以用动态链接库的形式存在，在应用程序需 要的时候再调入内存执行，以减少系统开销。 2 3 1 5r e s o u r c el a y e r 该层实际上是各个物理资源实体的总和，包括n m s 电话语音 、t t ss e r v e r 、a s r s e r v e r 和网络文件服务器等。 憩索郏电大学硕士学缎论文媒律辍务器戆赘源骛壤 銎4 媒体服务嚣黥分层设计结构 2 3 。2 系统管理： 一个电信级系统的运行维护工作是十分复杂、繁琰的，e e 如我霄j 采用了工控机+ 电话 语音卡的方式来实现媒体服务器的基本硬件配置，而这种配置本身的稳定性是有限的。遽 样，在工控机的型母、插槽和板卡的型号、数量之间具有一定的旺配关系。如果在一个：” ： 控机上加载了过多的板卡，系统就很有可能会因为总线信号干扰溅扳卡间的电磁干扰而产 生数据失真、无效的现象。其次，对于一个较为复杂的电信系统，备物理节点之间的琏线 毒届遣要遵矮一定驰蕊戴，尽量减少线鼯之耀懿信号干扰。 所良，一个瞧辘建好翦媒体骚务器疲强舆宥一个篱骧、裹效弱管理接霜，鞋支簿系统 维护人员对予多媒体资源方便地进行各种管理操作。 由于采用了分腠设计的体系结构，各个服务可以作为单独的进稗运转，若干服务对象既 可以运行在同一个物理节点上，也可以分布在互不相关的若干物理节点上，统一对上面的 m a n a g e m e n tl a y e r 负责。由于系统结构的黧火变化，系统管理也需骤进行相应的调整：可以 在每一个服务对象掰雀的物理岿点开发一个管理对象，耀予对该黢努对象进行直接管理，为 系统维护天受提供纛羰有效憨鹜形纯蓉理接嗣，毙絮敬蛰象诧的方式显示控嫠瑶物理诲点 上各通道的信令连接情况，或正在执行的动作。出于对计冀杭内存空闻承lc p u 处理遽度 的考虑，由于图形化界面会大人增加操作系统的开销，也可以将遮魑信息平时以文本的方 式显示给管理员，在需要的时候，再由管理员艏动图形化监控界面，直观地检夯系统的运 行状态：或者将消息上报给m a n a g e m e n tl a y e r 的管理对象，将系统各个服务的运行情况汇 总，进行统一管理刊每该接 ：_ 】交给n m p 处理。 北京邮电大学硕士学位论文媒体服务器的资源管理 系统管理对象的结构图如下 图5 系统管理功能结构图 媒体服务器可以分布在同一个局域网，也可以在i n t e m e t 网上，其各层次可扩展成集 群服务，所以它有很强的健壮性，单个物理节点的故障不会影响系统服务。而且这种分布 式系统配置经过资源管理层的统一控制，动态计算网络资源和媒体服务器的系统负载，可 以实现全系统的负载均衡，使用户的请求能得到最好的满足。 在各层的管理模块中增加统计功能。 1 统计日常用户所调用的各种业务的使用频率。我们可以根据这些数据来决定系统 资源的配置情况，调用次数多的就多分配一些硬件资源，调用次数少的就少分配一 些硬件资源，使得系统的静态资源配置尽可能达到最优化，减少使用过程中因为某 种业务的需要而动态配置资源所导致的系统开销。 2 。统计各种业务的执行情况，根据这些信息来判断系统中是否存在一些隐形的问题 和故障需要予以解决，以及它们可能的原因。 建立完备的日志系统，提供系统维护所需要的必要信息，如某次操作失败的时间、事 件发生的位置等，这有助于系统维护人员及时、准确地发现问题、定位问题和找到解决问 题的办法。 增加系统管理接口，对于不同的刚户开设不同权限的管理接口，要求用户输入用户名、 密码，经过核实后进入系统后，允许其对系统的运行进行不同级别的管理、维护操作。这 样，有助丁二提高系统管理的安全性和可靠性。应当为系统管理员提供一些对丁二系统故障进 行紧急处理的命令消息，使其在特定情况下执行特定的操作。比如，某个资源管理层的物 理节点出现了故障，需要重新启动，再次初始化板忙的硬件资源配置，则系统管理员可以 临时启动应急命令，向资源管理层发出请求，在该控制层物理节点上暂时无业务运行时， 将该资源：1 ，点设定为不可川状态，此时将所有的业务呼叫自动负载到其他的控制层物理节 点上去；然后发出命令，重新启动该控制层物理仃点的控制程序。 2 3 3 采用多线程技术提高系统的运行效率： 多线群技术白出现至今经历了很k 的发展时期，已经比较成熟，由丁采圳多线样技术 可以彳丁效地提高系统的处理述度，具有很强的伸缩性和可扩展性。闪此，有必要采 多 l 京郏毫大学骚学挝谂文焱体骚务器翦资源管壤 线程技术来提高系统的性能。 线程定义 一般来说，我们把程序的一次执行称为进程( p r o c e s $ ) 。一个进程包括一个程序 模块和该模块一次执行时所处理的数据。每个进程与其它进程拥有不同的数据块， 其内存地址是分开的。进程之间的通僚簧通过寻址，一般需使用信号、管道等进行 逶售。线摇( t h r e a d ) 是捂遴器内部一毅霹狻立撬毒亍携毒狻烹控稍淀戆擐令j 事列。 子线程与其父线程共享一个地蛙空阗，潮个任务中的不阏线程共享任务盼各顼资 源。 多线程与多进程的主要区别在于，线程是一个进程中段独立的控制流，一个 进程可以拥有若干个线程。在多进程设计中各个进程之间的数据块是相互独立的， 一般彼此不影响，要通过信号、管道簿进行交流。而在多线程设计中，各个线程不 一定独立，羁一铿务中豹各个线程共攀程痔段、数据段等资源。多线程毙多进程受 方霞于共享资源 多线程技术 使用多线穰_ 技术能有效地帮助你寓现应用程序的更高性能和更优良的可伸缩性。 但在真正运用遮项技术的时候务必小心。 如果做得不对，多线程编程势必会打开“潘朵拉的盒子”( 意思是说惹出无数的麻 烦) 。重复性不明箍、产生程序垃圾、记数器没有正确增值等等。你的应用程序还可 戆突然挂起。铡翔，数撂瘁连接这类炎澈藏可能基久意瓣遣关阉或者交褥过载。 实际上，痿动3 个线程醴百万分之一的步长计算因竭率掰游耗的时阕就毙露一线 程重复计算3 次要长得多。为什么会出现这种失败的情形观? 原因就在于，并行计辣 可以用到的一次计算期间却没有空闲周期，操作系统还要为调度线程之间的切换而税 费大量的时间。 为什么要用多线程 如果弥的疲嗣程_ 拳需要采取以下的操作，那么像尽可在缡穰静漪候考虑多线程执 裁： 连续的操作，需要花费忍无可慰的过长时间才可能完成 并行计算 为了等待网络、文件系统、用户域其他i o 响应而耗费大量的执行时间 对媒体骚务瓣懿体系结构进 亍分辑，裁会发现，妇采只是麓攀缝采翔单线程摸式， 系统藏要花费丈鬃造畦闻瘸在霹络数据髂惠翡转送霸揍彀上，褥期是采胡了瑟趣连接 的s o c k e t 端口涞传送消息后更是如此。这是因为t c p 协议楚谣向连接的协议，类似 于打电话，在开始传输数据之前，必须先建立明确的连接。耐凰。t c p 建立在i p 之上 ( 这正是t c p i p 的由来) ，定义了网络上程序到程序的数据传输格式和规则，提供丁 i p 数据包的传输确认、丢失数据包的蘧新请求、将收到的数据包按照它们的发送次序 重新装配的枫铡。雨且，应崩程序在调j _ = | 底层板卡驱动程序掰提供的a p i 时，也要遗 行一定豹i o 擞侉，& 强，搔数语音辩，雷先要抒舞语音文# | 二，然蓐霉终沿煮数嚣谤 贝鲻投d s p 瓣缓冲区里，在这个过秘中，应羽程序只能等待。所以，采穰多线穰技 术，可以从消极地等待i o 响应中争取劁不少时间埘于计算，越能够提高系统的运行 效率的。 线程池 魏京鄄电丈学硬士学德论文媒体驻务器鲍资滚簿壤 活动的线程会消耗系统资源。在一个系统里创建太多的线穰可能会导致系统由于斑 度消耗内存而用宪内存或“切换过度”。为了防止资源不足，应用程序需要一些办法来限 制任何给定时刻处理的请求数目。 线程池为线程生命周期开销问题芹口资源不足问题提供了解决方案。通过对多个任 务重用线程，线攫创建的开销被分摊到了多个任务上。其好处是，因为在请求到达对 线程已经存在，掰戳无意孛氇瀵除了绞瑗创建蕊带来豹延迟。逮拱，蓑可敬立静请求 服务，饺应霜程净喻应更侠。露量，遥避适当地调整线程洮巾的线程数器，也就怒警 请求的数目超过某个阈值时，就强嵩其它任何新到的请求一嫩等待，直到获得一个线 程来处理为止，从而可以防止资源不足。 当系统采用了分层设计的思想后，锫个服务可以灵活，独立地进行配置，这既方便于 系统的统一调发秘罄瑾，也有利于采用多线程枫剽来提供整个系统静运行效率。比如，诳 潋在s e r v i c el a y e r 滋孛戆语音瓣务璧。j c 雩予来鑫上层豹i n a p 涟悫耱疯层上掇戆事姊瓣 处理，用一个线稷米完成；圈对对于管瑗对象的消息处理和该服务对象的实时运行情况躲 监控，启用另一线稷来处理。又如，在a p p l i c a t i o nl a y e r 层，对于每个动态加载的业务实例 对象( 比如u p t ，m a s 等) ，都启用一个对应的业务线程来控制其执行流程。当直接分配所 需线程数量过多，导致消耗大量的系统资源时，可以采用线程池的方法来改进。 在采罔多线羧皴魏岳，为了保证各个线程塞藏、稳定遣工 挈，嚣簧浚诗一个线程管壤 对象，对番线疆逑行统一调度和管理。该对象负责益撬稻管理簿令线程瓣运行装态，魄 如在没有处理任务时暂时挂起某个线糨，事件到来时再唤醒该线程：当发现菜个线稷状 态异常时，可以强制其死亡，重新启动个新的线程等。 2 3 4 该设计方案的优点： 该设计方寰避大的特点就是系统分层之后，各种服务的配置非常灵活，既可以将若 干服务配置在同一物理节点上，又可以将它们分散在若干个物理节点上，从丽具有分帮式 懿特点各个鬏务之瓣槎互弦立，馁予独立调试纛穆造萁独立豹罄理接登窍应蠲接爨，鞠 互之间的干扰明照减少 提高了系统的胃扩震性和稳定性；分屡斡多线程结构可殴大大降 低系统中并发的总线程数，从而避免不必要的系统调度开销，有利于提高媒体服务器的 性能。 北京邮电大学硕士学位论文媒体服务器的资源管理 第三章资源管理模型的设计方案 3 1 资源管理层的设计 3 1 1 资源管理层的设计目标 媒体服务器应当具有一个完善的管理系统，它需要具有以下特征： 具有符合中国用户管理特点和使用习惯的管理决策系统，为企业决策者及相关 维护人员、管理人员提供有力支持；管理方便而又全面，可对资源设备进行实时的 监督管理，可进行事后的回顾、分析和预测。 资源管理层负责维护和管理系统中各种资源的具体运行状态，包括各种硬件资源 ( 如r n ) 和软件资源( 如语音文件) ，对应用层提供一个抽象的、透明的、统一的调用 接口，对应用层屏蔽了底层各种资源的细节，比如某个通道是d i a l o g i c 板卡的还是n i s 板卡的。 当有多个控制层资源节点存在时，资源管理层应当实时记录各资源节点的资源调度 情况。系统在运行中，实现将业务呼叫处理动态地均衡负载，避免出现一部分控制层资 源节点处于极度的繁忙之中，导致性能下降，另一部分控制层资源节点却十分空闲的情 况，从而使整个系统的性能达到最优化。这就需要有一个功能齐备的负载均衡算法了。 同时，资源管理层对服务层的各服务进程提供通信连接，采用l a n 的方式，以s o c k e t 连接来实现消息的收发。 在智能业务节点中，业务层是采用c n 来实现的，c n 中包含有虚拟机、编译器等功 能实体。然后，用自定义的u l s c r i p t 。c 语言编写好业务文件后，经过编译器的编译， 生成执行代码流，再交给虚拟机去调用底层的资源管理来实现既定的操作。业务层 和资源管理层之间的消息交互基本上是遵循i n a p 协议的。由于底层资源的多样性 和复杂性，现阶段的i n a p 协议并不能全部实现，所以，还定义了一些私有消息以 实现特定的功能。 在n g n 的体系结构中，为了适应电信业务开放性的要求，应用层可以采用应 用服务器的方式来实现。应用服务器上提供了各种业务应用可编程接口( a p i ) 。它定 义了一套技术独立的接口，这些接口规定了方法、事件、参数及语义，使得外部( 不信 任的第三方) 的和内部的( 传统网络运营者) 应用创作者可以控制核心网络资源。p a r l a y 系统可为访问基于网络的p a r l a y 业务的外部应用提供资源地位、认证和授权功能，使 得不必对软交换设备的功能进行升级就能实现增值业务的开发管理和应用。通过在应用 服务器上运行p a r l a y 应用程序，网络运营者提供p a r l a y 网关，负责访问业务提供者网 络的安全和管理，使n g n 可以安全、有效、快速实现新业务的应用。业务的启动、加 载和管理： ：作都是由应用服务器来完成的。应用服务器拥有一个业务库，当收到米自资 源管理层的业务呼叫请求后，就启动一个相应的业务。为了保证整个系统的可靠性和健 壮性，每当有一个业务将要启动时，应用服务器应当检测系统中止在运行的业务是否会 与其产生干扰，如果会产生干扰，则应当采用一些特定的措施实时监控并管理可能发生 的异常情况。这样，在应用服务器中还要有一个对于各种业务运行情况的管理表，实时 监控各业务的启动、运行午结束。作为资源管理层，应当对应_ l | ；j 服务器提供p a r l a y 标 准的消息接口，而将底层资源调度平管理的具体细1 ，对上层予以屏敞。这样，在应用服 务器看来，姒体服务器是一个提供了p a r l a y 标准接口的核心资源网络。目前p a r l a y 服 务器由箨个网络运营商提供，只是冈为p a r l a y 还没有规定与各底层网络的资源接口， 4 就家郏电夫学硬圭学德论文媒髂服务器豹资源管溪 所以p a r l a y 服务器和各通信嘲之闯暂时其能由网络运营商蟊融设定内部的通信协议， 在可编程交换机系统中，采用i n a p 将a p i 映射到低层网络。p a r l a y 客户端是通过调用 p a r l a y a p i s 访问p a r l a y 服务器，它们之间一般采用c o r b a 等分布对象技术进行通信。 3 。1 2 资源管理屡的设计方案 姿滚管理爱分笼嚣个逶程：a g e n t 靼a d a p t e r 。 a g e n t 是一个通信代理，它应当具有以下功能： 适应通倍实体的可变性。 由予系统必须不问断运行，系统的几个组成部分必须具有动态更新的能 力。比如我们增加了一个资源节点或者一个资源节点出现故障，绝对不能影响 整个系统豹正常运行。 适疲避镶实俸静异建分毒性。 与冀健功能之闯的距离不能成为通信质量的制约因素。 通信实体的附加功能 通倍实体除了基本的通信服务以外，还需要有一贱更高级的通信服务，比 如通信同步、广播、通信对端毕逝、通信实体鉴权及身份验证等功能。比如通 信过程中对端早释会导致通信中断，通信代理必须确定该状态并将其原本承摁 静王撵转移到蚤翔节点上。 a g e n t 进程与服务层的各服务实体通谶s o c k e t 来进行连接，管理底层的s o c k e t 道 信，控制各个s o c k e t 的开关闭合和消息的接收和发送。各服努进程作为c 1 i e n t 端，启 动时主动向作为服务器端的a g e n t 发起谶接，每隔1 5 秒钟将会收到从a g e n t 来的例梭 消息，收到后应该给a g e n t 回送例检消息，作为对于该通信管道可靠性的检查。各服务 实体孛设置定时器，如果在援定对趣内未曾牧到从a g e n t 来的经俺消息，刚认为该避道 畜强嚣，簸务进释圭麓淘a g e n t 豪起羲瓣连接秘请求；若重逢多次都未戒动，翼摄务实 体应当跌文本、弹i 嗽式对话框或警笛声的方式发出警报信息，擒醒系统维护人员翦采维 修。 a g e n t 与服务层各服务实体之间的通信是一对多的对应关系，它既可以将底层的消 息传递给上面的成用层，又可以将底层菜个端点的消息转发给底层的另一个端点去使 用。由于对i o 端鞠进行读写会耗费大缀的j j 寸间，为了提高a g e n t 进程的处理速度，这 里采臻多线程技术，秘对每个通信蠛翻设定一个工作线程，簸羧该通信端日豹漕惠遁髂。 弱霹，a g e n t 避稷孛鸯一个对予各漠患避遂送行标识戆淀患逶邋滚，簇来薅善瀵患逶遴 统一管理，并鼠作为各服务实体注册艏埘阐的标志。a g e n t 在收到从底层来的消息赢， 根据消息的目的地将该消息发送给相应的目的实体，并对该消息重新进行封装，在消息 头中添加消息通道标志信息，以便目的嵌体识别消息流传递的途径。当a d a p t e r 进程取 得业务消息厉，撤据要发送的目的地而决定使用哪一个消息通道来f 发消息，同样要襁 消息头中添加消患通道标识信息。 a d a p t e r 进稳受舞进行资源| ! 毫管理翻调度，消息静延瑶爨| 转发。簌a g e n t 麓港意酞 列中取出各服务送来的消息，经过必要的处理后转发给应j ； j 屡；或者从应用层收到相麻 的消息后，经过必骤的处理后，再转发给相应的服务实体去处理。a d a p t e r 进程与a g e n t 进科之间的通信是一对一的关系。 系统中，消息从底层功能模块到高层业务模块之间的消息交蛆必然要1 1 ，帮个系统的 爨褰露羲走学臻妻擎袋德囊爨臻疆务器彝簧海蛰爨 监务箍疆靖黼辩帮势，黠于蘩翡濑蟪液速度抟彩嗡不察想箍。器忿。我嚣j 褒潦诗懑蘸 内部的通信擦黝时，宥必要考廊内部接附的通信速度要求。 出于业舞然能聪港务量会增大，嫩挚瓣系统效事的考瓣，遮攫狭定采鲻共宰内嚣的 方式来实现a d a p t e r 与a g e n t 之间的消想交互。 戡掇攀蛰蛩 掏6a g e n t 国a d a p t 材之间静潲储糟斌 囊饕嚣溪鬻麟冀是羚嘉法串，黎遵，螽寒誊遵霸潦蕊袈慈薷邃曩糕褰霉辩蒸 篷建蠹获疆港嚣。薅攘舔荚享逡毒鹣蠢蕊，虿舞遴纛之藏掩蕊数糍莓萋壹揍蔌糖蕊蕊露 存彀。事实土，躲攀内存是凡释i p c 荐法审效霉最毒斡一辩。巍莱令迸覆委谯搜瓣 莰共享蠢存酣- 凇它进程必须譬持撩檄僚貉柬才靛使溺。邋神秘调祝囊可跌掰穗碍灯激 实现。 辔予莱鬻巍襻攫羚配鹫己经规患苫蠢臻空间魏大小，穗燃烧霞避毒亍对霹靛会戡燃蛾 舅鬓蹇茇巍辫黪溅象，曼妻瓣t 粒避辫戆予过囊载运孬对，褥髓会导蘩共享搀毒嚣爨淄 甭馨，蓉蠹藤凌瓣雾黎蘩嚣。鬟蒜，焘了憝疆这一喾臻蘩穗，簸餐霞簧霉鸯鏊乏耪叉瓣 杂了毒蠡餐道鹣滚穗隽式；塞鏊蛰灏按鼹：牧裂一蕊遴意，滚澄穰疑遘a g e n t 箍霎爨翳麟 转发给a d a p t e r ，褥此时共享内存联辩剩佘空间大小不知怒谢怒够。可以通道蕊靛热攀 内存医剩余窝嗍的大小来予以确定，谶斑个共享内存剩寐燃问最小值，当幕4 余窝闸襻 餐小予此最小瓣撼灌时，猁可调用谢端辫道麴酒纛传送枫谁嫩谶孝亍溺怠麓笈送鞠稽槛。 当蛰控到剩容嫩赫麓大小超过了最小裂娥蠖黠，嬲可以调燃搀攀穗孬曲方式来处勰。姻 麓帮g 冬女g 毪髓e 之怒蕊i p c 蘩蘼筵攀港誊毒褒雾遵羹煮戏拳赛餐。羹了疆多瀵惑碴 送辩嚣，霹袋避& 嚣# 冀瑟霹t # r 乏溺浚蒋蠢菱送餮蕊枣袋液努憨鬟立一交螯遴瀵意恣 存嚣郓接收淤愈内眷甄。 资源管粼黧越褥繇管理统一艘拣a d a p t e r 送程中去赎燃。粉予每静资源帮设跫一个 资源分配对擞。姆个资源分配对象有诚撰资源的忙闲表溅满空闲资源队列，当收剐一 个谈求淡息麟，龉技一个空阂资源，搏器避弱榴窟资源对搬姻拣嵩。在媒体目务器申燕 委奏竣f j t 转瓷灏；l 。语音逶邈2 会波毯嚣爱祷囊囊赣。对于凝幸母爨每一个c h a n n e l + 帮赋予一卞避耩土藏c 辍n n e l l # 蕊孽，黠蕊避露蓬一蛰莲，浚c h a r m e ! 鬟震懿秘鼍、 羲擎孽、羲器蕊聚帮资雾； 纛号簿藩惑郡疑谈c h a n 嚣e l 蕊蕊稔：饕箕嚣装在夺漆巍然 表构造蛇数攒辩橱中。 通道资渊铃碟糍的数据结构如f * 北京邮电大学硕士学位论文媒体服务器的资源管理 i n tn c h a n n e l i d i n tn s p a n i d ： i n tn b l o c k l d ： i n tn b l o c k t y p e i n tn r e s n o d e i d 表示该通道的逻辑编号 表示该通道位于板卡的那个e 1 上 表示该通道位于哪个板卡上 表示该通道所在板卡的类别、型号 表示该通道所在的资源控制节点的逻辑编 ? 马 表示该通道目前的状态： 1 异常，不可用；2 尚未连通，空闲； 3 尚未连通，正在进行信令操作； 1 1 3 已连通，尚未进行任何操作； 4 已连通，正在放音；5 己连通，正在录音； 6 已连通，正在收号：7 已连通，会议； 1 1 8 己连通，正在收传真； 9 已连通，正在发传真； l o 已连通，正在发送固网短信： s t r u c tc h a n n e l n o d e * p n e x t n o d e s t r u c tc h a n n e l n o d e * p p r e v n o d e 除此之外，还要对系统中会议资源、传真资源、i v r 资源、t t s 服务器、a s r 服务器等资源进行管理，有必要对这些资源建一个表。当业务层中的某个业务需要 调用某种资源进行操作时，首先要向资源管理层中资源管理对象的发出资源申请， 只有当资源管理对象检索了相关的资源管理表后，发现有剩余资源可以使用，并给 该业务返回相应的资源逻辑号时，业务才能顺利地进行下一步的动作，实现预定的 目标。否则，业务应当提示用户：网络资源目前紧张，请稍后再申请该业务。比如， 某一时刻系统中的传真资源已经用完了，而此时某个用户申请发送传真到他所在的 传真机上，则对该请求将予以拒绝。又比如，某个会议的资源所允许会议中的成员 人数为5 0 人，而在某一时刻，这些坐席全部占满了，则如有一个用户要求加入该 会议，业务向a d a p t e r 发出申请，a d a p t e r 应当返回资源申请失败消息，予以拒绝。 这样，系统对于正在运行中的各种资源都有一个简明而又清晰的管理，避免当一些 业务当某些资源尚不在状态时发送一些操作命令到资源控制层去执行，从而引起业 务异常失败，或导致系统中某些资源的状态异常，无法继续使用，并减少了不必要 的系统开销，类似于一种资源预留机制。 【注意：资源管理层根据所管理的控制层资源节点的信息，成功地给业务分配了 相应的资源后，就会按照业务的需要向服务层发送相应的控制消息，以执行下一 步操作。每条消息的头部必须包含一个字段，标志所对应的控制层资源节点编号， 以便服务层正确地定位控制层资源节点的位置。而且，消息包中的其它信息都是 经过资源管理层查表后取得的实际的控制层资源节点上的的对应数据，相当于做 了一次翻译工作。比如某个n c h a n n e l i d 只是媒体服务器中的一个逻辑编号，资源 管理层需要将它映射为某个控制层资源节点上实际的语音通道编号。为了简明起 见，后面各服务实体从资源管理层收到的消息的消息结构中不列出该字段，只在 这里作出简要说明。】 j 泰辩毫大学赣学位谂支 媒髂骚务器馥螯漂繁理 会议瓣务资源表的数据结构海。 s t r u c tc o n f r e s n o d e i n tn c o n f r e s i d ： i n tn r e s n e d e i f ) ； i n t 溺镕e o 缸整e m b e r n u m b e r i n tn b l o c k t y p e s t r u c tc o n f r e s n o d e * p n e x t s t r u c tc o n f r e s n o d e 柚p r e y 铸囊熙势资源表盼数据结构为 表示该会议资源的逻辑号 表示该会议资源耩茬豹姿嚣节患i d 警 表示在该会议瓷源上开委斡嚣膏会谈 囊l 容霸躲簸大戒员数 表示该会议资源的板卡类型： 1 n m s2 d i a l o g i c3 s a n h u i d s t r u c tf a x r e s n o d e i n tn f a x r e s i d ； 表示该黄真资源熬澄辍号 i n ta r e s n o d e i d ； 表示该会筏资源掰在薛爨溪苇点 号 i n tn b l o c k l d ；表示该簧真姿浮掰在的援卡! b 号 i n tn m a x f a x m e m b e r n u m b e r ；表示该传真资源所燮持的最大传真避遂数 i n