专利名称：：共享内存流媒体服务器的运行方法及其功能模块构架的制作方法
技术领域：
：本发明属于一种流媒体服务器，特别是一种内核进程和用户进程采用共享内存的流媒体服务器的运行方法及该服务器为实现其运行方法的功能模块构架。
背景技术：
：近年来，随着高速网络、高带宽存储设备以及媒体编码压縮技术的迅速发展，使得通过网络提供实时流媒体服务成为可能。流媒体技术广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电视台和实时视频会议等互联网信息服务的方方面面。流媒体应用的关键问题是流媒体服务器的性能，多数在数字媒体领域著名的公司都开发推出了包括服务器和播放器在内的一整套流媒体解决方案。目前，流媒体服务器优化的热点主要有将点对点技术与流媒体整合，克服了传统C/S结构容易出现的瓶颈问题；新的媒体编码技术的出现，提供了数据量更小，解析度更高的流媒体格式供服务器使用；根据流媒体的特性设计专门的嵌入式硬件，为服务器提供额外硬件支持等。传统流媒体服务器大多运行在用户态，用户态进程的i/o操作需要通过系统调用陷入内核，最终在内核态完成i/o操作后，再返回用户态继续执行后续指令。这里提到的用户态和内核态是在类Unix操作系统中广泛采用的概念，即当一个进程在用户态下运行时，它不能直接访问内核的数据结构和程序，也不能直接和硬件资源交互。因此，当一个在用户态下运行的服务器读文件时就会切换到内核态、执行被严格限制的目的的内核运行过程；而当内核完成读文件操作时，又需返回用户态；然后，服务器进程又需要再次切换到内核态下将数据包从网络发送给客户。和文件服务器类似，为保证流媒体的实时性，服务器必须将流媒体文件分割成小数据包，并将每个数据包实时地、独立地发送给客户端。由于每次I/0操作请求都要由用户态进程通过系统调用来完成，因此，这类服务器在运行过程中必然产生大量I/0操作。据粗略统计，一个长度为一分钟左右、数据率为lmbits/s的mp4格式媒体文件用流媒体服务器发送时、产生的数据包个数在6000到7000左右，这就意味着为客户播放一次这个文件，服务器每秒将执行100次以上的网络I/O操作。在Linux平台下，这种来回切换是通过CPU硬件支持的模式切换机制来完成的；系统调用通过中断(执行"int0x80"汇编指令)或者执行sysenter指令(需要特定CPU支持和Linux2.6内核)切换到内核态，并通过调用一内核函数来完成。此外，要使内核实现多个不同系统调用，用户态进程必须传递一个系统调用号作为参数来指定请求的系统调用，然后CPU执行以下3*CPU特权级切换、堆栈切换和程序指针转换；*在内核栈上保存寄存器的值；*通过调用相应的C函数(系统调用服务例程)处理系统调用；*退出为寄存器载入保存在内核栈上的值，CPU切换回用户态。附图2即为
背景技术：
流媒体服务器工作原理示意图。因而，
背景技术：
存在服务器在运行过程中需频繁、且反复采用I/O操作来完成媒体文件的发送，其运行程序繁琐；服务器为此需付出非常可观的性能开销，CPU的有效利用率低，严重地降低了网络传送系统的吞吐量及流媒体的传输效率，提高了运行成本等弊病。
发明内容本发明的目的是针对
背景技术：
存在的缺陷，研究设计一种共享内存流媒体服务器的运行方法及其功能模块构架，将用户态和内核态之间的通信通过共享内存进行，使用户态进程和内核进程都可以像访问自己地址空间内的其他内存一样访问这块共享内存。从而达到简化媒体文件传送流程，提高CPU的有效利用率及网络传送系统的效率，增大客户吞吐量，降低服务器的运行成本等目的。本发明的解决方案是将RTSP(实时流协议)处理和RTP(实时传输协议)发包处理分成两个子系统，分别由两个进程实现，这两个子系统使用一块共享内存来共享协同工作所必需的数据，即首先在服务器内由内核态进程申请(请求)一块物理内存、作为RTSP及RTP两个子系统的共享内存(跨越内核态和用户态的共享内存)，使用户态进程和内核态进程都可以像访问自己地址空间内的其他内存一样访问该共享内存，同时将系统中所有的RTP会话都存放在这块内存中，使服务器中的读文件和网络发包不再通过系统调用，直接调用内核中与网络I/0相关(对应)的函数就能完成，从而实现本发明的目的。因此，本发明方法包括A.建立共享内存首先由内核态进程请求系统分配一块内存，并将该内存的起始物理地址存储到一个内核全局变量中，用户态进程通过系统调用取出该起始地址，同时将其映射到自己的地址空间；在内核态和用户态之间建立共享内存；B.运行方法为1.0:接收客户请求并依次转入步骤1.1;1.1:处理请求并根据请求内容及RTSP协议向客户发送相应的响应；1.2:判断是否满足客户请求，如果能满足请求，则转入步骤2.0，否则返回步骤l.l处理下一个请求；2.0:将客户请求内容存入共享内存后，转入步骤3.0;43.0:将系统从用户态的RTSP处理流程转入内核态的RTP处理流程；4.0:从共享内存上提取请求内容，并转入步骤4.1;4.1:根据请求内容中的发包时间先后排序后，转入步骤4.2;4.2:判断当前的数据包是否为应发数据包，如果是，则转入步骤5.0，否则返回步骤4.1重新排序；5.0:根据应发数据包描述信息生成RTP包，并转入步骤5.1;5.1:发送当前RTP包至客户，并判断发送完毕与否，如果是，则转入步骤6.0待机，否则继续发送流程。上述共享内存流媒体服务器的运行方法所用功能模块构架(装置)包括一个接收用户请求的单元；一个用于处理用户请求并向用户发送响应的单元；一个判断系统能否满足用户请求的判断处理单元；一个将请求内容存入的共享内存单元；一个将系统从用户态的RTSP处理流程转入内核态的RTP处理流程的系统转换单元；一个从共享内存提取请求内容的提取处理单元；一个可根据请求内容中的发包时间排序的排序处理单元；一个判断当前数据包是否为应发数据包的判断处理单元；一个可根据应发数据包描述信息生成RTP包的处理单元；一个发送RTP包及判断发送完毕与否的发送及判断单元。本发明由于将RTSP(实时流协议)处理和RTP(实时传输协议)发包处理分成两个子系统，分别由一个用户进程和一个内核进程实现，这两个子系统使用一块共享内存来共享协同工作所必需的数据；即首先由内核态进程请求系统分配一块内存，同时将系统中所有的RTP会话都存放在这块内存中，使服务器中的读文件和网络发包不再通过系统调用、也不需进行状态切换，直接在内核态下便可顺利完成，从而简化了流媒体文件传送流程，提高了CPU的有效利用率及流媒体服务器吞吐量。在相同硬件条件下，经对比测试
背景技术：
在并发客户数达到400时，发包延迟急剧增大，CPU占用率达到饱和状态；而本发明在并发客户数达到500时，CPU占用率才达到饱和状态；本发明较
背景技术：
明显减少了内核态和用户态之间的状态切换和数据拷贝次数，其客户吞吐量及CPU的有效利用率提高25%以上。因而，本发明具有流媒体文件的传送过程简捷，CPU的有效利用率及网络传送系统的效率高，流媒体服务器客户吞吐量大，服务器运行成本低等特点。图1为本发明流媒体服务器工作原理示意图；图2为
背景技术：
流媒体服务器工作原理示意图；200910058193.5图3为本发明流媒体服务器工作流程示意图(方框图)。具体实施例方式以在硬件配置为CPU:PentiumIII，799.786MHz;内存256M字节;硬盘20G，5400转/分，操作系统为Linux的PC机上运行本发明流媒体服务器为例A.建立共享内存首先由内核态下的RTP子系统申请分配一块内存，然后按设定数据结构初始化该内存，并将其起始物理地址存入一个内核全局变量中；RTSP子系统通过系统调用获取共享内存的起始物理地址，再将这块内存映射到自己的地址空间；此时，RTP子系统和RTSP子系统均能跨越内核态和用户态共享该块内存；B.运行方法为现以完整的客户服务流程为例接收客户请求l.O及处理请求并发送响应1.1均与
背景技术：
对应的流程相同，即对客户的OPTION请求及其响应原则、DESCRIBE请求及其响应原则、SETUP请求及其响应原则以及PLAY请求及其响应原则均与
背景技术：
相同；当服务器能满足PLAY请求(步骤1.2)时，服务器即生成一个表示媒体文件传送任务的数据结构，并把它存入共享内存内(步骤2.0);这个数据结构称为RTP会话，其内容包括关于客户和被请求的媒体文件的描述信息；RTSP子系统这个动作的意义在于，将发送媒体文件的任务存入共享内存中，以方便RTP子系统提取任务；在RTSP子系统结束上述流程后，系统从RTSP处理流程转入RTP处理流程(步骤3.0);RTP子系统访问共享内存(步骤4.0)，读取步骤2.0中存入的RTP会话，以获取RTSP子系统传递过来的关于客户和媒体文件的描述信息；RTP子系统和RTSP子系统在共享内存中完成数据的交接；根据RTP会话描述的下一包的发包时间的先后排序(步骤4.1);按其排定的先后次序依次处理，如果当前数据包的应发时间在当前时间之后则返回步骤4.1，重新排序，若当前数据包为应发数据包则进入步骤5.0;RTP子系统按照媒体文件的编码格式，调用读文件的内核函数从媒体文件中读入相应的数据并加上RTP协议头部生成RTP包(步骤5.0);步骤5.1根据共享内存上RTP会话中的发送目的地(客户的IP地址和端口号)，调用网络发包内核函数，把RTP包发送至客户，直到满足条件的包发送完毕。自动转入下一个RTP会话并重复执行上述流程，直到所有RTP会话都没有满足发送条件的包或服务完毕，系统进入待机状态，直到发包时间到达或新客户请求达到。采用本实施例的方法进行仿真运行实验，测试其能够承受的最大并发客户数。运行实验选取码率为100kbits/s的mp4格式电影文件作为测试用媒体文件，选取小码率文件的优点在于能够在不达到以太网网络带宽的硬件限制的前提下、尽可能增加发包操作密度，加大服务器的负载。测试方法为以3秒为周期对服务器运行状态做采样，测试项目包括6每秒平均发包(RTP包)数、正在播放状态的客户数、最大的发包延迟和平均发包延迟。发包延迟是指实际发包时间和这个RTP包的应发包时间的差值，这是反映服务器工作性能的重要指标。发包延迟过长将会造成客户端在期望的时间点接收不到数据、发生播放无法进行的情况(故障)。在服务器轻载工作时，这个延迟会维持在一个稳定的时间范围内；当服务器在重负载条件下工作时，某些发包动作会被适当延迟，而在服务器的负载超过上限时，发包动作延迟时间则会急剧升高，同时造成客户端异常。本实验并发客户数以每次增加50户的量，逐渐加大服务器的负载，当并发客户数达到500户时，观察到发包延迟时间显著增长(即当前最大发包延迟时间由450个客户时的3毫秒陡增至500个客户时的133毫秒)，与此同时，正在播放中的客户播放器出现跳帧和画面停顿等异常情况；可以推断服务器已经超过处理能力的上限。实验数据如下表<table>tableseeoriginaldocumentpage7</column></row><table>再通过top指令测定服务器的CPU占用率对上述结果进行验证，此时，服务器的CPU占用率采样数据分别为用户19.5%，系统78.1%，空闲2.8%，即CPU已处于满载状态。然后，对
背景技术：
流媒体服务器在相同硬、软件及操作条件下做相同实验，实验数据如下表<table>tableseeoriginaldocumentpage7</column></row><table>即当并发客户数达到400户时，最大发包延迟时间由350个客户时的4毫秒陡增至400个客户时的215毫秒；CPU亦处于满载状态。两次实验结果对比本实施例方法在重载正常工作时，平均每秒发包数较
背景技术：
增加3925个，客户吞吐量提高25%以上。权利要求1.一种共享内存流媒体服务器的运行方法，包括A.建立共享内存首先由内核态进程请求系统分配一块内存，并将该内存的起始物理地址存储到一个内核全局变量中，同时将该物理地址映射到用户态进程的地址空间；在内核态和用户态之间建立共享内存；B.运行方法为1.0接收客户请求并依次转入步骤1.1处理；1.1处理请求并根据请求内容及RTSP协议向客户发送相应的响应；1.2判断是否满足客户请求，如果能满足请求，则转入步骤2.0，否则返回步骤1.1处理下一个请求；2.0将客户请求内容存入共享内存后，转入步骤3.0；3.0将系统从用户态的RTSP处理流程转入内核态的RTP处理流程；4.0从共享内存上提取请求内容后，转入步骤4.1；4.1根据请求内容中的发包时间先后排序后，转入步骤4.2；4.2判断当前的数据包是否为应发数据包，如果是，则转入步骤5.0，否则返回步骤4.1重新排序；5.0根据应发数据包描述信息生成RTP包，并转入步骤5.1；5.1发送当前RTP包至客户，并判断发送完毕与否，如果是，则转入步骤6.0待机，否则继续发送流程。2.按权利要求l所述共享内存流媒体服务器的运行方法所用功能模块构架，包括一个接收用户请求的单元；一个用于处理用户请求并向用户发送响应的单元；一个判断系统能否满足用户请求的判断处理单元；一个将请求内容存入的共享内存单元；一个将系统从用户态的RTSP处理流程转入内核态的RTP处理流程的系统转换单元；一个从共享内存提取请求内容的提取处理单元；一个可根据请求内容中的发包时间排序的排序处理单元；一个判断当前数据包是否为应发数据包的判断处理单元；一个可根据应发数据包描述信息生成RTP包的处理单元；一个发送RTP包及判断发送完毕与否的发送及判断单元。全文摘要该发明属于一种共享内存流媒体服务器的运行方法及实现其方法的功能模块构架，包括建立共享内存，接收并处理客户请求，将请求内容存入共享内存，系统从用户态转入内核态流程，从共享内存上提取请求内容并按发包时间先后排序，生成RTP包并发送至客户；以及与上述步骤对应的各功能模块单元。该发明由于将RTSP和RTP分成两个共享一块内存的子系统，使内核态进程读文件和网络发包不再通过系统调用、也不需状态切换，直接在内核态下便可顺利完成。经对比测试客户吞吐量及CPU有效利用率提高25％以上。而具有流媒体文件传送过程简捷，CPU的有效利用率及网络传送系统的效率高，流媒体服务器客户吞吐量大，服务器运行成本低等特点。文档编号H04L29/06GK101478549SQ20091005819公开日2009年7月8日申请日期2009年1月20日优先权日2009年1月20日发明者毅李,杨晓冬,鹏王,旭董,宇辜申请人:电子科技大学