1、 本科毕业论文 题 目 基于 Apple Darwin 的流媒体消息管理服务器的设计与实现 Design and Implementation of Streaming Media Message Management Server Based On Apple Darwin 姓 名 学 号 专 业 计算机科学与技术 指导教师 职 称 讲师 /硕士 中国 武汉 二 一 七 年 五 月 华中农业大学楚天学院本科毕业论文（设计） 分类号 密级 华中农业大学楚天学院本科毕业论文 基于 Apple Darwin 的流媒体消息管理服务器的设计与实现 Design and Implementation o
2、f Streaming Media Message Management Server Based on Apple Darwin 学生姓名： 学生学号： 学生专业：计算机科学与技术 指导教师： 华中农业大学楚天学院 二一 七 年 五 月 华中农业大学楚天学院本科毕业论文（设计） 目 录 摘要 . I 关键词 . I Abstract . I Key words. I 1 系统的可行性研究概述 .1 1.1 课题背景及研究现状 .1 1.2 课题意义 .1 1.3 课题目标 .1 2 系统相关技术与协议 .1 2.1 主体框架 .2 2.2 RTSP 协议 .3 2.3 SDP 协议 .3 2
3、.4 RTP 协议 .3 2.5 RTCP 控制协议 .4 3 流媒体消息管理服务器 设计 .4 3.1 流媒体消息服务器的系统框架 .4 3.2 客户端请求到服务器的过程 .5 3.3 客户端请求在线流媒体信息的过程 .7 3.4 客户端请求摄像头的实时视频信息的过程 .8 3.5 Camera 录像的过程 .9 3.6 CMS 服务器的接口设计 . 10 4 流媒体消息服务器实现 . 12 4.1 流媒体交互中的消息传递设计 . 12 4.2 客户端登录到服务器的实现过程 . 13 4.3 客户端请求在线流媒体信息的实现过程 . 14 4.4 客户端请求通道摄像机实时码流推送 . 16 4
4、.5 客户端退出系统的实现 . 17 4.6 服务器系统登出的实现 . 18 5 系统测试 . 20 5.1 测试的方法 . 20 5.2 测试过程 . 20 5.3 测试总结 . 22 参考文献 . 23 致谢 . 24华中农业大学楚天学院本科毕业论文（设计） I 摘 要 流媒体消息管理服务器 在整个流媒体服务器中作 为 全局交 互的角色，在 服务器项目中负责全局的消息管理，用来处理所有的相关的业务请求。该服务器是基于 Darwin 的 基础上开发的，它的作用是分离 Darwin 中消息处理部分，让 Darwin 将主要的业务放在流媒体的处理上。流媒体消息管理服务器是用来处理用户的请求以及在
5、整个流媒体服务器中各功能部分的 交互部分。 开发基于 Darwin 的流媒体服务器使用 VS2008 作为开发工具，整个服务器的开发过程主要的解决方案是处理各服务器部分的信息交互部分，对于客户端使用 HTTP 协议来进行信息交互，服务器之间使用 RSTP 协议来进行信息交互。 关键词 流媒体；消息管理服务器；消息交互；设备接入； Abstract Streaming media message management server as a global interactive role in the streaming media server,that is responsible for
6、global in the whole project,where use to handle all related service requests. The server is developed on the basis of Darwin, and its role is to separate the message processing part of Darwin, and let Darwin put the main business on the processing of streaming media. The streaming media management s
7、erver is mainly used to process the users request and the request interaction part of each functional part in the entire streaming media server. The development of the streaming media server using Darwin VS2008 as a development tool based on the whole development process of the main server solution
8、is part of the interactive information processing server, the client uses the HTTP protocol to exchange information, the server uses the RSTP protocol to exchange information. Key words Streaming; Media Message Management Server; Message Interaction; Device Access; 华中农业大学楚天学院本科毕业论文（设计） 1 1 系统 的可行性研究
9、概述 1.1 课题背景及研究现状 随着无线网络的飞速发展和技术的不断更新，互联网已经普及到每一个普通的家庭。 Internet的基础架构慢慢趋于完善，对于网络上信息的交互结构已经发生了本质上的改变。从最开始的基本的文字信息和图片信息到了现在大容量、高信息量的流媒体信息。已经不是仅仅只有图片信息就能满足用户的需求了，而现在的电子竞技行业也是十分火热，各大赛事直播也是一个非常火热场景。在当下这个人们需求大量视频数据传播的背景下一个好的稳定的快速的流媒体服务器是十分有必要的。人们迫切的希望看到实时的 场景直播，对于直播的画面也是有一个高清的要求。在当前的流媒体领域，有以下三种占着主导地位它们分别是
10、Apple公司的 Quick Time、 Microsoft公司的 Media Server以及 Real公司的 Real System。 其中 Apple Darwin是苹果公司开源的一个非常优秀的流媒体服务器。而本文就是基于该服务器的基础开发的关于在流媒体服务器运行过程中的所有的关于数据访问部分的服务器器设计，是整个流媒体服务器中关于消息的服务器。对于一个流媒体服务器而言，主要的实现部分是流媒体服务器来实现流媒体数据的 推送。而对于信息交互而言苹果开源的服务器是提供 Darwin来处理这个过程的。本文是基于 Darwin的基础来开发，所做的内容主要是将消息处理部分相关的内容独立出来，通过消
11、息服务器来处理整个流媒体服务器中的信息交互部分，而 Darwin主要去处理流媒体信息的推送相关的部分。将消息处理的部分独立出来提高整个流媒体的服务器的效率性，各个模块由对应的部分去处理，各模块独立又相互交叉的去处理业务。 1.2 课题意义 在实际应用中，用户对于通过互联网获取视频音频的消息，于是流媒体应运而生，满足了用户对于网上高质量多媒体信息 的需要。而随着技术的跟新与迭代，人们对现阶段的流媒体有了新的要求，想要有更好的用户体验，能够实时的无延迟的去观看直播视频。通过网络实时的去监控部署的摄像头下的视频数据也是一个在原有的基础上的更好的体验，能够实时的观察家中的状况，或者监控某一块地域的实时
12、情况。而这些技术也将广泛的应用于多媒体的新闻在线、直播、远程教育、视频点播、实时视频回忆等广泛的方面。 1.3 课题目标 本课题的目标为在一个流媒体服务器中实现一个中心管理服务器 （ CMS） ，该中心管理服务器用于实现整个流媒体服务器中的信息交互和视频信息推送。当 客户端发送数据请求时，中心管理服务器服务处理该用户请求，并将该请求发送到流媒体服务器中，待流媒体服务器对该请求做出了响应后处理该响应结果并反馈给客户端。客户端在发送录像请求的时候，中心管理服务器处理该用户请求，并将该请求发送到 Camera录像相关的服务上面， Camera录像服务去处理该录像的请求。中心管理服务器负责处理整个请求
13、的交互过程。在整个流媒体服务处理的相关交互过程中都会设计到信息的交互和回馈处理，中心管理服务器的作用就相当于中国的古老职业邮差，它负责传递获取这些信息，然后解析这些信息并将它推送到相应 的处理模块当中。 2 系统相关技术与协议 Darwin Streaming Server简称 DSS， DSS作为 Apple公司提供的开源实时流媒体播放服务器程序。整个服务器 使用 C+编写 ， 在设计上遵循高性能 、 简单 、 模块化等程序设计原则， 在使用上具有高效性和可扩展性。为了提高流媒体服务器处理请求的效率，消息管理服务器正式基于 DSS来单独分离出消息处理模块用于接收和处理服务器系统之间的请求，让
14、 DSS将主要的功能用于做流媒体消息推流上。各应用部分之间的请求通过消息流媒体服务器器处理之后，将信息指令传递给 DSS。 华中农业大学楚天学院本科毕业论文（设计） 2 2.1 主体框架 Darwin流媒体服务器是由一个父进程构成的，在该父进程中分叉出来的一个子进程，作为服务器的核心服务器。运行中父进程会等待子进程，当子进程发生退出错误的时候，父进程会分叉出新的子进程。分叉出来的子进程的作用是作为充当网络客户和服务器模块的接口，对于网络客户通过RTP和 RTSP协议来发送请求信息和接收响应信息，而对于服务器模块，它是负责处理各种请求和向客户端发送信息数据包。核心服务器是通过创建几种类型的服务线
15、程来完成自己各模块相关的工作，具体如下： 服务器本身拥有自己的主线程（ Main Thread）。这个主线程主要负责检查当前服务器是否需要关闭，记录当前状态信息，或者打印当前统计信息。空闲任务线程（ Idle Task Thread）。空闲任务线程主要管理一个周期性的任务队列。这种任务队列有两种类型：套接口任务和事件线程（ Event Thread）。事件线程主要是负责侦听套接口的任务事件，比如收到了 RTSP请求或者 RTP数据包，之后把事件传递到任务线程中处理。服务器中会存在一个或者多个处理任务的线程。任务线程主要是负责从事件线程中去接收 RTSP和 RTP请求，然后把接收到的请求传递到恰
16、当的服务器模 块去做对应的处理，然后把数据包反馈给客户端。在缺省情况下，核心服务器会为每一个处理器去创建一个任务线程。 图 2-1 总结了客户端，核心服务器的线程，和服务器模块之间的关系 。 图 2-1 Darwin 服务器架构 由于服务器中的线程在处理上是异步的，所以对于不同的事件需要提供一个对应的通讯机制。例如当某个用于处理 RTSP连接的套接口得到请求数据的时候，需要去通知某些组件，来处理数据，而任务对 象就是用来处理这种通讯的机制。 对于每个任务对象都存在两个主要的通讯方法 Signal和 Run。服务器通过调用 Signal方法来传递Task对象给对象，对于 Run方法是用来指定处理
17、任务的对象的。每个 Task对象的处理方法都是通过用小的非阻塞的时间片段来完成服务器的功能。在 Run函数的内部， Task对象通过调用 GetEvents函数来接收当前的和先前已经用信号通知过的事件，并自动使该事件退出队列。 Run函数是永远不可重入的，如果一个 Task对象在其 Run函数中调用 GetEvents函数，然后在 Run函数完成之前又发出信号，则该 Run函数只有在当前的函数实例退出之后，才能（因为那个新的事件）再次被调用。事实上， Task对象的 Run函数会被反复调用，直到该对象的所有事件全部被 GetEvents函数清除掉为止。 这个事件触发任务 的核心概念被集成到几乎
18、每一个流媒体服务器的子系统中。举例来说，一个Task对象可能和一个套接口 Socket对象相关联。如果 Socket对象得到一个事件通过 select通知，或者通过 Mac OS X的时间队列，则相应的 Task对象就会得到信号通知。在这种情况下， Run函数的函数体华中农业大学楚天学院本科毕业论文（设计） 3 中就会包含相应的代码，来处理在该 Socket对象上接收到的任何事件。 Task对象使得流媒体服务器用单独一个线程来运行所有连接的做法成为可能 ，这正是流媒体服务器在单处理器系统上的缺省设置。 Darwin流媒体服务器使用模块来相应各种请求完成请求任务，主要有三种模块内容管理模块、服务
19、器支持模块、访问控制模块。所有的信息交互功能和流媒体消息推送模块都是在 Darwin上完成的，本系统的设计是基于 Darwin服务器的。其核心的功能是将消息处理的部分从 Darwin服务器中分离出来，所以系统设计之初通过分析 Darwin服务器对于其模块分类分割之后。流媒体消息服务器主要是将内容管理模块分离出来做单独的数据交互处理。 内容消息模块是负责管理和媒体源相关的 RSTP请求和相应，所以流媒体消息管理服务器的主要功能就是用于处理消息交互的。消息处理后和 Darwin进行交互，将对应的请求发送给 Darwin，然后让 Darwin去处理对用的请求内容。 2.2 RTSP 协议 作为一个应
20、用层协议， RTSP提供了对外可供扩展的应用框架，这个意义在于使得实时流媒体的数据变得可控，从而让点播变得可行。总体来说， RTSP协议是一个流媒体表示层的协议，主要是用于控制具有实时特性的数据，但是它本身是不传输数据的，而是必须通过依赖于下层传输协议所提供服务来传递数据。 RTSP协议可以对流媒体服务提 供播放、暂停、快进等相关的数据操作，它主要用于定义具体的控制消息、操作方法、状态码等，同时还定义了和 RTP之间的数据交互。 RTSP协议在制定时较多地参考了 HTTP1.1协议，甚至许多的描述和 HTTP/1.1是完全相同的。 RTSP之所以特意的去使用与 HTTP/1.1类似的语法和操作
21、，在很大程度上是为了考虑兼容现有的 Web基础结构。虽然RTSP服务器同样也使用标识符来区别每个会话流连接的 Session，但是 RTSP连接并不会因此绑定到传输层的连接，也就是说对于整个的 RTSP在连接期间， RTSP用户是可以打开或者 关闭多个对 RTSP服务器的可靠传输连接来发出 RTSP请求。同时， RTSP协议也是基于面向无连接的传输协议的如 UDP等。 一次基本的 RTSP连接操作过程是，首先，客户端会发送一个 RTSP描述命令 DESCRIBE来连接到流服务器。在流服务器中通过一个 SDP来进行描述反馈，描述反馈包含流数量、媒体类型等数据信息。在客户端通过分析该 SDP，并为
22、会话中的每一个流发送一个 SETUP建立的 RTSP流命令， RTSP流命令会传递给服务器，客户端用来接收媒体数据的端口。流媒体连接建立成功后，客户端会发送一个播放请求命令 PLAY，服务器就会开始在 UDP上传送媒体流 RTP包反馈给客户端。 在播放的过程中客户端还可以向服务器发送相应的命令来控制视频流的快进、快退和暂停等。最后，客户端通过发送一个终止命令 TERADOWN来结束本次的流媒体会话。 2.3 SDP 协议 SDP传递着媒体流信息，接收者可以解析传入的 SDP数据，从而知道发送者的基本信息。 SDP基本上在 Internet上工作。 SDP定义了会话描述的统一格式，但不会定义多播
23、地址的分配和 SDP消息的传输方式，也不支持媒体编码方案的协商，这些功能均由下层传送协议完成。 SDP完全是一种会话描述格式 ,它不属于任何传输协议 ,它只用于使用对应的传输协议，这些协议包括 SAP会话通知协议、 RTSP实时流协议、 MIME电子邮件的扩展协议以及 HTTP超文本传输协议。由于 SDP协议本身是基于文本的协议，因此 SDP协议的可扩展性是比较强的，在很多场景下都会广泛的用到 SDP协议。SDP本身是不支持会话内容和媒体编码的协商，所以在流媒体中媒体协商这一块要用 RTSP来实现。SDP 完全是一种会话描述格式 ,它不属于传输协议 ,它只使用不同的适当的传输协议，包括会话通知
24、协议 SAP、会话初始协议 SIP、实时流协议 RTSP、 MIME 扩展协议的电子邮件以及超文本传输协议HTTP。 SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。 SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用 RTSP来实现。 2.4 RTP 协议 RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个 RTP数据报都由头部华中农业大学楚天学院本科毕业论文（设计） 4 Header和负载 Payload两个部分组成，其中头部前 12个字节的含义是固定的，而负载则可以是音频或者视频数
25、据。其中比较重要的几个域及其意 义， CSRC记数 CC表示 CSRC标识的数目。 CSRC标识紧跟在 RTP固定头部之后，用来表示 RTP数据报的来源， RTP协议允许在同一个会话中存在多个数据源，它们可以通过 RTP混合器合并为一个数据源。例如，可以产生一个 CSRC列表来表示一个电话会议，该会议通过一个 RTP混合器将所有讲话者的语音数据组合为一个 RTP数据源。负载类型 PT标明 RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型 2表明该 RTP数据包中承载的是用 ITU G.721算法编码的语音数据，采样频率为 8000Hz，并且采用单声 道。序列号用来为接收
26、方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情， RTP协议本身并不负责数据的重传。时间戳记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。从 RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。 RTP协议的目的是提供实时数据如交互式的音频和视频的端到端传输服务，因此在 RTP中没有连接的概念 ，它可以建立在底层的面向连接或面向非连接的传输协议之上。 RTP也不依赖于特别的网络地址格式，而仅仅
27、只需要底层传输协议支持组帧 Framing和分段 Segmentation就足够了。另外 RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下， RTP一般是在传输协议之上作为应用程序的一部分加以实现的。 2.5 RTCP 控制协议 RTCP控制协议本身不单独使用，需要和 RTP协议一起使用，当在应用程序中开启了 RPT回话时，会同时占用两个对应的端口，这两个端口对应 RTP和 PTCR的连接接口。 RTP协议并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由 RTCP来负责完成。通常 RTCP会采用与 RTP相同的分发机制，向
28、会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从数据中读取相关数据，以及网络状况、分组丢失概率等反馈信息。 RTCP协议通过不同的 RTCP数据报来传递，主要有几种类型。 SR发送端报告，发出 RTP数据报的应用程序或者终端称为发送端，发送端同时也可以是接收端。 RR接收端报告，所谓接收端是指仅接收但不发送 RTP数据报的应用程序或者终端 。 SDES源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。BYE通知离开。主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。 3 流
29、媒体消息管理服务器 设计 3.1 流媒体消息服务器的系统框架 流媒体服务器作为整个系统的交互部分负责处理来自设备的注册连接和其他的各个服务器节点的连接，流媒体服务器 Darwin的接入请求、录像管理服务的接入请求、来自于客户端的接入请求。对于所有设备关于连接的维护和管理或控制操 作命令的发送，设备信息的上报解析来自客户端的请求都是在中心管理服务器上处理的。图 3-1总结了整个的请求流程。 华中农业大学楚天学院本科毕业论文（设计） 5 图 3-1 流媒体服务器的系统框架图 这是整个服务器中的通讯流程的系统设计，其中消息交互如图 3-2 所示。 C M S 服 务 器C M S 服 务 器C a
30、m e r aC a m e r aC l i e n tC l i e n tC M S 服 务 器C M S 服 务 器D a r w i nD a r w i nR M SR M S图 3-2 流媒体服务器的消息传递图 从消息流程图中可以看出， 对于整个系统而言，在设计上是功能分离的，每一个功能部分都是由对于的系统 服务来执行。这样子进行业务分离对于系统的健壮性而言是很有必要的， 可以让服务器有一个更大的数据负载量。 3.2 客户端请求到服务器的过程 从 流媒体服务器的系统框架图中可以看出，对于整个的流媒体服务器而言是分为很多的服务器模块的。这样子分化模块也是为了将服务器处理的功能模块抽
31、取出来，每一个服务器做专门的业务服务，这样子对整个流媒体服务器而言可以很大程度的提高服务的处理业务和负载能力。对整个流媒体服务器而言，中心管理服务器是处理整个服务器体系中信息流的核心组件。可以说整个系统的交互性都是在这里完成的，如过这个地方的业务出现了问题那么整个流媒体系统是无法正常运转的。所以在设计过程中，这一块的交互性显然是重中之重 ，在设计的过程中，各系统的交互设计是非常的重要的。 从服务器的开启来分析整体的设计流程。如图 3-3所示显示的是整个流媒体服务器开启的时候所需要做的工作。 Darwin流媒体服务器开启， CMS服务器开启， RMS服务器开启，摄像头相关的服务器开启，数据库 R
32、edis相关的服务器也启动，这些服务器在一个网络端中启动，所以在通信上是没有什么问题的。服务器都开启成功后，服务器之间必然是会有一定的数据交互过程。 CMS服务器将其他的功能服务器的消息记录到本机中，关于其他服务器的数据是存储到 Redis中的。在客户端发起来华中农业大学楚天学院本科毕业论文（设计） 6 请求 后，会去数据库中找处理对应请求的服务器模块，通过之前存储的数据去找到相应的处理模块，通过发送交互请求来等待对应的服务器返回消息，交互连同后开始业务处理的信息指令传递。 服 务 器 开 启服 务 器 开 启R M S 服 务 器R M S 服 务 器D a r w i n 服 务 器D a
33、 r w i n 服 务 器C a m e r aC a m e r aC M S 服 务 器C M S 服 务 器R e d i sR e d i s结 束结 束图 3-3 服务器开器处理过程图 服务器正常开启成功后级开始进入到，处理功能交互的过程了。各服务器将数据注册到了消息服务器中，也通过请求进行了系统交 互。再设计过程中将服务器都设计在同一网络段保重数据交互的通透性， 数据访问交互的过程如图 3-4 所示。 CMS服 务 器CMS服 务 器数 据 库 服 务 器数 据 库 服 务 器RedisRedis开 始开 始结 束结 束图 3-4 服务器数据交互过程 CMS数据库和数据库之间的处理流程是双向的，发送请求后能够很快的从数据库中获取到对应的数据。使用的数据库是 Redis，这是一个采用键值对存储的数据，所以对应数据的索引是非常的迅速的，因此对应数据的交互而言体验感是很强的，不存在卡顿和延迟。 服务器启动连接完毕后开始功能方面的设计，图 3-5是客户端登录到数据的流程，在客户端登录到服务器时，客户端向流媒体消息服务器发送一个登录请求。流媒体消息服务器获取到该请求后，解析该请求中的信息，获取登录的客户端的用户名、 密码、端口号以及 IP地址。然后向 Redis数据库
