基于Apple-Darwin的流媒体消息管理服务器的设计与实现

本科毕业论文题 目基于Apple Darwin的流媒体消息管理服务器的设计与实现Design and Implementation of Streaming Media Message Management Server Based On Apple Darwin姓 名学 号专 业计算机科学与技术指导教师职 称讲师/硕士中国武汉二一七年五月华中农业大学楚天学院本科毕业论文（设计）分类号 密级华中农业大学楚天学院本科毕业论文基于Apple Darwin的流媒体消息管理服务器的设计与实现Design and Implementation of Streaming Media Message Management Server Based on Apple Darwin 学生姓名： 学生学号：学生专业：计算机科学与技术指导教师： 华中农业大学楚天学院二一七年五月目 录摘要I关键词IAbstractIKey wordsI1 系统的可行性研究概述11.1 课题背景及研究现状11.2 课题意义11.3 课题目标12 系统相关技术与协议12.1 主体框架22.2 RTSP协议32.3 SDP协议32.4 RTP协议32.5 RTCP控制协议43 流媒体消息管理服务器设计43.1 流媒体消息服务器的系统框架43.2 客户端请求到服务器的过程53.3 客户端请求在线流媒体信息的过程73.4 客户端请求摄像头的实时视频信息的过程83.5 Camera录像的过程93.6 CMS服务器的接口设计104 流媒体消息服务器实现124.1 流媒体交互中的消息传递设计124.2 客户端登录到服务器的实现过程134.3 客户端请求在线流媒体信息的实现过程144.4 客户端请求通道摄像机实时码流推送164.5 客户端退出系统的实现174.6服务器系统登出的实现185 系统测试205.1 测试的方法205.2 测试过程205.3 测试总结22参考文献23致谢24摘 要流媒体消息管理服务器在整个流媒体服务器中作为全局交互的角色，在服务器项目中负责全局的消息管理，用来处理所有的相关的业务请求。该服务器是基于Darwin的基础上开发的，它的作用是分离Darwin中消息处理部分，让Darwin将主要的业务放在流媒体的处理上。流媒体消息管理服务器是用来处理用户的请求以及在整个流媒体服务器中各功能部分的交互部分。开发基于Darwin的流媒体服务器使用VS2008作为开发工具，整个服务器的开发过程主要的解决方案是处理各服务器部分的信息交互部分，对于客户端使用HTTP协议来进行信息交互，服务器之间使用RSTP协议来进行信息交互。关键词 流媒体；消息管理服务器；消息交互；设备接入；AbstractStreaming media message management server as a global interactive role in the streaming media server,that is responsible for 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 server 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 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 wordsStreaming; Media Message Management Server; Message Interaction; Device Access; I1 系统的可行性研究概述1.1 课题背景及研究现状随着无线网络的飞速发展和技术的不断更新，互联网已经普及到每一个普通的家庭。Internet的基础架构慢慢趋于完善，对于网络上信息的交互结构已经发生了本质上的改变。从最开始的基本的文字信息和图片信息到了现在大容量、高信息量的流媒体信息。已经不是仅仅只有图片信息就能满足用户的需求了，而现在的电子竞技行业也是十分火热，各大赛事直播也是一个非常火热场景。在当下这个人们需求大量视频数据传播的背景下一个好的稳定的快速的流媒体服务器是十分有必要的。人们迫切的希望看到实时的场景直播，对于直播的画面也是有一个高清的要求。在当前的流媒体领域，有以下三种占着主导地位它们分别是Apple公司的Quick Time、Microsoft公司的Media Server以及Real公司的Real System。其中Apple Darwin是苹果公司开源的一个非常优秀的流媒体服务器。而本文就是基于该服务器的基础开发的关于在流媒体服务器运行过程中的所有的关于数据访问部分的服务器器设计，是整个流媒体服务器中关于消息的服务器。对于一个流媒体服务器而言，主要的实现部分是流媒体服务器来实现流媒体数据的推送。而对于信息交互而言苹果开源的服务器是提供Darwin来处理这个过程的。本文是基于Darwin的基础来开发，所做的内容主要是将消息处理部分相关的内容独立出来，通过消息服务器来处理整个流媒体服务器中的信息交互部分，而Darwin主要去处理流媒体信息的推送相关的部分。将消息处理的部分独立出来提高整个流媒体的服务器的效率性，各个模块由对应的部分去处理，各模块独立又相互交叉的去处理业务。1.2 课题意义在实际应用中，用户对于通过互联网获取视频音频的消息，于是流媒体应运而生，满足了用户对于网上高质量多媒体信息的需要。而随着技术的跟新与迭代，人们对现阶段的流媒体有了新的要求，想要有更好的用户体验，能够实时的无延迟的去观看直播视频。通过网络实时的去监控部署的摄像头下的视频数据也是一个在原有的基础上的更好的体验，能够实时的观察家中的状况，或者监控某一块地域的实时情况。而这些技术也将广泛的应用于多媒体的新闻在线、直播、远程教育、视频点播、实时视频回忆等广泛的方面。1.3 课题目标本课题的目标为在一个流媒体服务器中实现一个中心管理服务器（CMS），该中心管理服务器用于实现整个流媒体服务器中的信息交互和视频信息推送。当客户端发送数据请求时，中心管理服务器服务处理该用户请求，并将该请求发送到流媒体服务器中，待流媒体服务器对该请求做出了响应后处理该响应结果并反馈给客户端。客户端在发送录像请求的时候，中心管理服务器处理该用户请求，并将该请求发送到Camera录像相关的服务上面，Camera录像服务去处理该录像的请求。中心管理服务器负责处理整个请求的交互过程。在整个流媒体服务处理的相关交互过程中都会设计到信息的交互和回馈处理，中心管理服务器的作用就相当于中国的古老职业邮差，它负责传递获取这些信息，然后解析这些信息并将它推送到相应的处理模块当中。2 系统相关技术与协议Darwin Streaming Server简称DSS，DSS作为Apple公司提供的开源实时流媒体播放服务器程序。整个服务器使用C+编写，在设计上遵循高性能、简单、模块化等程序设计原则，在使用上具有高效性和可扩展性。为了提高流媒体服务器处理请求的效率，消息管理服务器正式基于DSS来单独分离出消息处理模块用于接收和处理服务器系统之间的请求，让DSS将主要的功能用于做流媒体消息推流上。各应用部分之间的请求通过消息流媒体服务器器处理之后，将信息指令传递给DSS。2.1 主体框架Darwin流媒体服务器是由一个父进程构成的，在该父进程中分叉出来的一个子进程，作为服务器的核心服务器。运行中父进程会等待子进程，当子进程发生退出错误的时候，父进程会分叉出新的子进程。分叉出来的子进程的作用是作为充当网络客户和服务器模块的接口，对于网络客户通过RTP和RTSP协议来发送请求信息和接收响应信息，而对于服务器模块，它是负责处理各种请求和向客户端发送信息数据包。核心服务器是通过创建几种类型的服务线程来完成自己各模块相关的工作，具体如下：服务器本身拥有自己的主线程（Main Thread）。这个主线程主要负责检查当前服务器是否需要关闭，记录当前状态信息，或者打印当前统计信息。空闲任务线程（Idle Task Thread）。空闲任务线程主要管理一个周期性的任务队列。这种任务队列有两种类型：套接口任务和事件线程（Event Thread）。事件线程主要是负责侦听套接口的任务事件，比如收到了RTSP请求或者RTP数据包，之后把事件传递到任务线程中处理。服务器中会存在一个或者多个处理任务的线程。任务线程主要是负责从事件线程中去接收RTSP和RTP请求，然后把接收到的请求传递到恰当的服务器模块去做对应的处理，然后把数据包反馈给客户端。在缺省情况下，核心服务器会为每一个处理器去创建一个任务线程。图2-1总结了客户端，核心服务器的线程，和服务器模块之间的关系。图2-1 Darwin服务器架构由于服务器中的线程在处理上是异步的，所以对于不同的事件需要提供一个对应的通讯机制。例如当某个用于处理RTSP连接的套接口得到请求数据的时候，需要去通知某些组件，来处理数据，而任务对象就是用来处理这种通讯的机制。对于每个任务对象都存在两个主要的通讯方法Signal和Run。服务器通过调用Signal方法来传递Task对象给对象，对于Run方法是用来指定处理任务的对象的。每个Task对象的处理方法都是通过用小的非阻塞的时间片段来完成服务器的功能。在Run函数的内部，Task对象通过调用GetEvents函数来接收当前的和先前已经用信号通知过的事件，并自动使该事件退出队列。Run函数是永远不可重入的，如果一个Task对象在其Run函数中调用GetEvents函数，然后在Run函数完成之前又发出信号，则该Run函数只有在当前的函数实例退出之后，才能（因为那个新的事件）再次被调用。事实上，Task对象的Run函数会被反复调用，直到该对象的所有事件全部被GetEvents函数清除掉为止。这个事件触发任务的核心概念被集成到几乎每一个流媒体服务器的子系统中。举例来说，一个Task对象可能和一个套接口Socket对象相关联。如果Socket对象得到一个事件通过select通知，或者通过Mac OS X的时间队列，则相应的Task对象就会得到信号通知。在这种情况下，Run函数的函数体中就会包含相应的代码，来处理在该Socket对象上接收到的任何事件。Task对象使得流媒体服务器用单独一个线程来运行所有连接的做法成为可能，这正是流媒体服务器在单处理器系统上的缺省设置。Darwin流媒体服务器使用模块来相应各种请求完成请求任务，主要有三种模块内容管理模块、服务器支持模块、访问控制模块。所有的信息交互功能和流媒体消息推送模块都是在Darwin上完成的，本系统的设计是基于Darwin服务器的。其核心的功能是将消息处理的部分从Darwin服务器中分离出来，所以系统设计之初通过分析Darwin服务器对于其模块分类分割之后。流媒体消息服务器主要是将内容管理模块分离出来做单独的数据交互处理。内容消息模块是负责管理和媒体源相关的RSTP请求和相应，所以流媒体消息管理服务器的主要功能就是用于处理消息交互的。消息处理后和Darwin进行交互，将对应的请求发送给Darwin，然后让Darwin去处理对用的请求内容。2.2 RTSP协议作为一个应用层协议，RTSP提供了对外可供扩展的应用框架，这个意义在于使得实时流媒体的数据变得可控，从而让点播变得可行。总体来说，RTSP协议是一个流媒体表示层的协议，主要是用于控制具有实时特性的数据，但是它本身是不传输数据的，而是必须通过依赖于下层传输协议所提供服务来传递数据。RTSP协议可以对流媒体服务提供播放、暂停、快进等相关的数据操作，它主要用于定义具体的控制消息、操作方法、状态码等，同时还定义了和RTP之间的数据交互。RTSP协议在制定时较多地参考了HTTP1.1协议，甚至许多的描述和HTTP/1.1是完全相同的。RTSP之所以特意的去使用与HTTP/1.1类似的语法和操作，在很大程度上是为了考虑兼容现有的Web基础结构。虽然RTSP服务器同样也使用标识符来区别每个会话流连接的Session，但是RTSP连接并不会因此绑定到传输层的连接，也就是说对于整个的RTSP在连接期间，RTSP用户是可以打开或者关闭多个对RTSP服务器的可靠传输连接来发出RTSP请求。同时，RTSP协议也是基于面向无连接的传输协议的如UDP等。一次基本的RTSP连接操作过程是，首先，客户端会发送一个RTSP描述命令DESCRIBE来连接到流服务器。在流服务器中通过一个SDP来进行描述反馈，描述反馈包含流数量、媒体类型等数据信息。在客户端通过分析该SDP，并为会话中的每一个流发送一个SETUP建立的RTSP流命令，RTSP流命令会传递给服务器，客户端用来接收媒体数据的端口。流媒体连接建立成功后，客户端会发送一个播放请求命令PLAY，服务器就会开始在UDP上传送媒体流RTP包反馈给客户端。 在播放的过程中客户端还可以向服务器发送相应的命令来控制视频流的快进、快退和暂停等。最后，客户端通过发送一个终止命令TERADOWN来结束本次的流媒体会话。2.3 SDP协议SDP传递着媒体流信息，接收者可以解析传入的SDP数据，从而知道发送者的基本信息。SDP基本上在Internet上工作。SDP定义了会话描述的统一格式，但不会定义多播地址的分配和SDP消息的传输方式，也不支持媒体编码方案的协商，这些功能均由下层传送协议完成。SDP完全是一种会话描述格式,它不属于任何传输协议,它只用于使用对应的传输协议，这些协议包括SAP会话通知协议、RTSP实时流协议、MIME电子邮件的扩展协议以及HTTP超文本传输协议。由于SDP协议本身是基于文本的协议，因此SDP协议的可扩展性是比较强的，在很多场景下都会广泛的用到SDP协议。SDP本身是不支持会话内容和媒体编码的协商，所以在流媒体中媒体协商这一块要用RTSP来实现。SDP 完全是一种会话描述格式,它不属于传输协议,它只使用不同的适当的传输协议，包括会话通知协议SAP、会话初始协议SIP、实时流协议RTSP、MIME 扩展协议的电子邮件以及超文本传输协议HTTP。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。SDP 不支持会话内容或媒体编码的协商，所以在流媒体中只用来描述媒体信息。媒体协商这一块要用RTSP来实现。2.4 RTP协议RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部Header和负载Payload两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。其中比较重要的几个域及其意义，CSRC记数CC表示CSRC标识的数目。CSRC标识紧跟在RTP固定头部之后，用来表示RTP数据报的来源，RTP协议允许在同一个会话中存在多个数据源，它们可以通过RTP混合器合并为一个数据源。例如，可以产生一个CSRC列表来表示一个电话会议，该会议通过一个RTP混合器将所有讲话者的语音数据组合为一个RTP数据源。负载类型PT标明RTP负载的格式，包括所采用的编码算法、采样频率、承载通道等。例如，类型2表明该RTP数据包中承载的是用ITU G.721算法编码的语音数据，采样频率为8000Hz，并且采用单声道。序列号用来为接收方提供探测数据丢失的方法，但如何处理丢失的数据则是应用程序自己的事情，RTP协议本身并不负责数据的重传。时间戳记录了负载中第一个字节的采样时间，接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响，但具体如何来补偿延迟抖动则是应用程序自己的事情。从RTP数据报的格式不难看出，它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息，这些都为实时的流媒体传输提供了相应的基础。RTP协议的目的是提供实时数据如交互式的音频和视频的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接或面向非连接的传输协议之上。RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧Framing和分段Segmentation就足够了。另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的。2.5 RTCP控制协议RTCP控制协议本身不单独使用，需要和RTP协议一起使用，当在应用程序中开启了RPT回话时，会同时占用两个对应的端口，这两个端口对应RTP和PTCR的连接接口。RTP协议并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从数据中读取相关数据，以及网络状况、分组丢失概率等反馈信息。 RTCP协议通过不同的RTCP数据报来传递，主要有几种类型。SR发送端报告，发出RTP数据报的应用程序或者终端称为发送端，发送端同时也可以是接收端。RR接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。SDES源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。BYE通知离开。主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。3 流媒体消息管理服务器设计3.1 流媒体消息服务器的系统框架流媒体服务器作为整个系统的交互部分负责处理来自设备的注册连接和其他的各个服务器节点的连接，流媒体服务器Darwin的接入请求、录像管理服务的接入请求、来自于客户端的接入请求。对于所有设备关于连接的维护和管理或控制操作命令的发送，设备信息的上报解析来自客户端的请求都是在中心管理服务器上处理的。图3-1总结了整个的请求流程。图3-1 流媒体服务器的系统框架图这是整个服务器中的通讯流程的系统设计，其中消息交互如图3-2所示。图3-2 流媒体服务器的消息传递图从消息流程图中可以看出，对于整个系统而言，在设计上是功能分离的，每一个功能部分都是由对于的系统服务来执行。这样子进行业务分离对于系统的健壮性而言是很有必要的，可以让服务器有一个更大的数据负载量。3.2 客户端请求到服务器的过程从流媒体服务器的系统框架图中可以看出，对于整个的流媒体服务器而言是分为很多的服务器模块的。这样子分化模块也是为了将服务器处理的功能模块抽取出来，每一个服务器做专门的业务服务，这样子对整个流媒体服务器而言可以很大程度的提高服务的处理业务和负载能力。对整个流媒体服务器而言，中心管理服务器是处理整个服务器体系中信息流的核心组件。可以说整个系统的交互性都是在这里完成的，如过这个地方的业务出现了问题那么整个流媒体系统是无法正常运转的。所以在设计过程中，这一块的交互性显然是重中之重，在设计的过程中，各系统的交互设计是非常的重要的。从服务器的开启来分析整体的设计流程。如图3-3所示显示的是整个流媒体服务器开启的时候所需要做的工作。Darwin流媒体服务器开启，CMS服务器开启，RMS服务器开启，摄像头相关的服务器开启，数据库Redis相关的服务器也启动，这些服务器在一个网络端中启动，所以在通信上是没有什么问题的。服务器都开启成功后，服务器之间必然是会有一定的数据交互过程。CMS服务器将其他的功能服务器的消息记录到本机中，关于其他服务器的数据是存储到Redis中的。在客户端发起来请求后，会去数据库中找处理对应请求的服务器模块，通过之前存储的数据去找到相应的处理模块，通过发送交互请求来等待对应的服务器返回消息，交互连同后开始业务处理的信息指令传递。图3-3 服务器开器处理过程图服务器正常开启成功后级开始进入到，处理功能交互的过程了。各服务器将数据注册到了消息服务器中，也通过请求进行了系统交互。再设计过程中将服务器都设计在同一网络段保重数据交互的通透性，数据访问交互的过程如图3-4所示。图3-4 服务器数据交互过程CMS数据库和数据库之间的处理流程是双向的，发送请求后能够很快的从数据库中获取到对应的数据。使用的数据库是Redis，这是一个采用键值对存储的数据，所以对应数据的索引是非常的迅速的，因此对应数据的交互而言体验感是很强的，不存在卡顿和延迟。服务器启动连接完毕后开始功能方面的设计，图3-5是客户端登录到数据的流程，在客户端登录到服务器时，客户端向流媒体消息服务器发送一个登录请求。流媒体消息服务器获取到该请求后，解析该请求中的信息，获取登录的客户端的用户名、密码、端口号以及IP地址。然后向Redis数据库请求数据去验证是否包含了当前的用户信息，如过没有就创建新的用户信息，并将结果反馈给客户端。客户端解析本次的反馈信息，登录成功进入主功能界面。图3-5 登录流程3.3 客户端请求在线流媒体信息的过程客户端登录完成后会向流媒体消息服务器发送一个获取当前服务器在线视频数据的列表。流媒体消息服务器获取到该请求后，将请求的数据封装成一条指令然后发送到Darwin服务器上去请求在线视频信息，Darwin处理该请求后会反馈一条处理信息给流媒体消息服务器，流媒体消息服务器将该反馈发送给客户端。同时Darwin将在线视频的数据推送给客户端，这样子就完成了一次视频请求的过程。在这个过程中客户端接收了来自服务器的视频数据，客户端点开视频数据可以开始异步的去加载视频信息观看，图3-6显示的是该请求流程。图3-6 获取在线视频列表在这个请求的交互过程中存在的流消息交互过程如图3-7所示，消息交互都是双向的，在交互过程中客户端使用的是HTTP请求到CMS服务器这段，而服务器之间的消息交互采用的是RTSP协议来保证协力的联通性。图3-7 获取在线视频列表信息交互过程这个交互过程中，CMS只负责信息的传递，对于视频流相关的信息是不通过CMS作为传递通道的，这个处理过程只包含着信息的交互过程。对这个请求过程中请求封装的消息只是交互双发的位置以及对应的协议信息对于具体的流媒体信息是通过专门的流媒体通道去进行流媒体数据传输的，这个传输过程是Darwin服务器来负责的，CMS服务器主要是处理消息请求，对流媒体请求只负责处理相关的命令请求过程。3.4 客户端请求摄像头的实时视频信息的过程客户端请求实时的摄像头视频信息，客户端向流媒体消息服务器发送一个请求信息，流媒体消息服务器解析该请求。将该请求信息发送给录像管理服务器请求摄像头的视频信息，录像管理服务器对该请求做出处理。录像管理服务器给摄像头发送录像请求，摄像头开始将当前镜头下的视频信息推送到Darwin服务器上，Darwin服务器获取到了当前的实时信息后将该视频信息推送到客户端上。Darwin对该推送过程反馈给流媒体消息服务器，流媒体消息服务器将该反馈信息发送给客户端。客户端获取到反馈信息和推送流视频后在本地去解析当前的视频流信息。对于视频流的数据解析是通过专门的数据解析算法来实现的，这部分的工作是在客户端上面去实现的，当CMS处理完这个请求后，Darwin服务器和客户但直接就有了一个流媒体的信息交互通道，视频流信息到了客户端后，对数据决心解析，最后在客户端上面就可以显示当前的实时视频信息，图3-8显示的是该请求流程。图3-8 获取实时摄像信息这一个请求过程是一个很复杂的信息交过程，这个请求过程中的信息处理部分包含了整个系统的所有的处理模块，所以在处理信息的交互过程中要保证信息传递的顺序性和实时性。只有这样子才能保证在信息处理的交互过程中。请求指令都有续的执行了，这样子才能得到系统设计所需要的效果，整个过程中的信息交互过程如图3-9所示。图3-9 实时视频的信息交互过程3.5 Camera录像的过程对应摄像头的摄像过程这一系统流程中的信息交互，如图3-10所示是整个交互过程中的信息流程。图3-10 录像的信息交互过程客户端请求录制视屏，消息管理服务器获取到该请求后将请求消息发送给Camera，摄像头开始录像，同时消息管理器也将该请求消息发送给力Darwin服务器和录像管理服务器。录像管理服务器负责在视频录制过程中，Camera将视频流推送给Darwin后，录像管理服务器获取该推送流数据存储到本地，同时将该存储消息备案到消息管理服务器中。消息管理服务器将该条录像消息反馈给客户端方便查询，图3-11显示的是该请求流程。 图3-11 Camera录像过程3.6 CMS服务器的接口设计作为与外接通信的接口，在设计服务器接口的时候需要考虑到负载量的问题，如果有大量的客户端接入过来，服务器这边如何去处理多设备。由于服务器的设计是多线程异步加载的，所以在设计的时候可以考虑提供尽可能多的接入口，而对于数据返回的接口应该减少数量，这样子可以同时加载尽可能多的客户端而不会出现长时间等待的问题，CMS接口的设计如图3-12所示。图3-12 客户端接入口设计从这个设计图中可以看出，对与CMS服务器而言提供大量的接入口，而反馈消息的接口设置的相对少一些，这样子可以去处理大量的客户端接入。在系统内部请求完成后将请求的结果返回回去，这样的过程是异步的所以不会造成线程堵塞，因此对于将回馈的接口设计的少一些是不会对系统造成影响的。上面介绍的是客户端和服务器之间的连接接口，下图3-13介绍的是服务器系统内部之间的接口设计。图3-13 系统接入口设计对于与系统之间的接口，必须是一对一对应的，因为使用的协议是RSTP协议，作为一种实时的协议不同于和客户端连接的接口需要实时连通。作为系统之间的交互，不仅仅只是通过接口连接成功就可以了，还需要将连接上来的服务器数据存储到数据库当中，因此需要设计和数据库交互的接口，在这个设计上是需要用到数据库服务来完成这对接的。图3-14 数据库接口设计对于数据库而言，接口在在设计的时候考虑的是唯一性，单个负载的系统在连接的时候只考虑去开放一个专门的接口去对应接收数据，因此这个接口的设计是单一的。同时也是最稳定的设计。摄像头和CMS的连接这之间是有一个录像管理服务器的，所以在设计的时候需要考虑到在这几个模块之间的衔接，如图3-15是关于录像服务的接口设计。图3-15 摄像接口设计由于需要考虑到实时视频数据和录像服务是需要同步进行的，因此在设计的时候需要考虑到数据的同步性，在处理推送同步视频数据的同时也需要发送录像的命，因此设计的时候需要将这个接口同步设置，让CMS可以同时去处理这些命令。4 流媒体消息服务器实现4.1 流媒体交互中的消息传递设计对于在消息交互过程中的交互方式协议的原则，协议的包含部分，消息的头部包含的信息以及消息主题部分携带的主体内容有一个明确的规定，以及定义详细的消息类型。交互协议设计原则,客户端与服务器通讯过程中，信息以消息为载体进行传输，每条消息都包含有消息头和消息的数据部分构成：消息头部以HTTP协议构成，以rnrn结尾；数据部分采用Json文本协议，保证协议高可读性和扩展性。消息类型定义对于数据的信息的交互，如果单纯的传递消息去解析会有很多的麻烦。所以对解析的信息做了一个统一的定义，每一个请求消息的类型事先声明好，在解析的时候根据事先定义好的数据类型去做相应的解析工作，这样对整个消息传递过程就有了一个很明确的流程。所以做了一下的信息类型定义。表4-1显示的定义的消息类型。表4-1 消息传递类型定义 描述MSG_DS_REGISTER_REQ 设备向CMS服务器发送的注册请求(周期性发送)MSG_SD_REGISTER_ACK 设备注册响应MSG_SD_PUSH_STREAM_REQ CMS向设备请求实时码流推送到DarwinMSG_DS_PUSH_STREAM_ACK 推流请求响应MSG_SD_STREAM_STOP_REQ CMS向设备请求停止实时码流推送MSG_DS_STREAM_STOP_ACK 停止命令响应MSG_SC_DEVICE_LIST_ACK 在线设备列表响应MSG_SC_DEVICE_INFO_ACK 设备具体信息响应MSG_SC_GET_STREAM_ACK 携带流媒体地址响应MSG_SC_FREE_STREAM_ACK 释放请求响应MSG_DS_POST_SNAP_REQ 设备向CMS上传视频快照MSG_SD_POST_SNAP_ACK快照响应MSG_SC_PTZ_CONTROL_ACKPtz控制请求回应4.2 客户端登录到服务器的实现过程客户端登录到服务器的这一个过程发送一个HTTP请求，请求中携带这Restful模式的JSON类型数据。JSON中封装了客户端的相关信息。CMS服务器接收到了这请求后，将数据存储到Redis数据库中作为一个Session存储。用以整个交互过程中的唯一识别标志来存储。在其他交互过程中用到的请求都是通过这次存储的数据作为一个索引表示来确定客户端的唯一性。这个信息的交互过程可以通过如图4-2的流程图中看出整体的过程。图4-2 数据存储消息指令的过程从图4-2中可以看出，当客户端登录进服务器系统后，所传递的主要信息是客户端的IP地址和Port端口号，CMS获取到这些信息后会和数据库服务器做一个信息交互，将这客户端的信息存储到Redis数据库中，做一个持久的存储，以方便后续的数据交互。这个交互过程在系统中不是唯一的，当客户端由于网络原因掉线重新登录后。CMS首先会到数据库中去检索是否已经存在了该条记录，如过存在更新记录的时间，删除数据库中旧的Session信息然后将现在登录的信息更新。这样子可以保证客户端在系统中的信息的稳定性，对后续的更能请求有一个好的信息维护。对于这个过程，在系统中的代码实现过程如图4-3所示。图4-3 数据存储消息指令的代码过程客户端登录进系统在CMS服务器中，首先是总的函数模块来加载整个注册方法，这个函数模块中包含数据库的连接和存储相关的方法没客户端接入后，会将相应的参数信息传递给注册方法，然后将数据存储到数据库中这样就完成了登录过程。4.3 客户端请求在线流媒体信息的实现过程请求RESTful,http:/ip:port/api/getdevicelist其中IP是服务器的IP地址，是根据请求的IP地址和本机的端口号来请求服务器响应数据的。响应：MSG_SC_DEVICE_LIST_ACK，相应头部携带着消息的请求类型，状态码和消息执行的信息。消息的主体部分携带着本次请求的客户端类型，序列编号，处理该消息的流媒体服务器信息，以及消息的处理码。从这些交互的信息就可以分析出整个的请求过程，客户端向CMS发起一个请求，请求的数据中携带着获取在线信息列表这个请求。消息管理服务器解析了这个请求，然后将处理后的消息返回过去，这样子一个交互过程就实现了，这个实现过程中的信息交互过程如图4-4所示。图4-4 传递在线流媒体信息的指令过程传递的接口中的信息类型都是事先已经定义好的数据类型通过这样的传递方式，讲数据指令在服务器端和客户端之间来进行信息通信。其中MSG_SC_DEVICE_LIST_ACK正是已经定义好了的请求在线视频信息列表的请求，在系统中的代码实现过程如图4-5所示。 图4-5 传递在线流媒体信息的代码过程客户端发送获取在线视频数据的请求，在实现的过程中首先是通过主函数模块来初始化所以的函数，对于客户端的请求，通过调用请求处理的方法来响应在线视频信息。4.4 客户端请求通道摄像机实时码流推送请求MSG_SD_PUSH_STREAM_REQ，请求的消息中包含着以下的信息，Serial设备序列号。Channe摄像机通道号。Protocol指定流媒体传输协议，如：RTSP、自定义协议等等。Server_IP推送码流到的流媒体服务器地址。Server_Port推送码流到的流媒体服务器端口。CMS为控制拉流和推流的合法性生成唯一的 StreamID并存储在 Redis上由Darwin进行判断是否合法。From：CMS接收Client访问的SessionID，To：CMS向 Device发送报文的SessionID，Via：CMS 的ServiceID，请求的消息传递指令过程可以通过图4-6来分析这个过程。图4-6 请求在线流媒体推送的指令过程响应：MSG_DS_PUSH_STREAM_ACK头部携带版本信息类型显示信息等类型的数据。消息主体部分携带序列编码，返回消息的个数，消息来源。消息接收点。其中还包含Server_IP和Server_Port 在此返回的是设备实际推流的IP和端口。以上就是在客户请求实时的监控视频的请求过程，消息管理服务器会向对应的服务发送相应的请求，然后解析返回过来的请求数据。图4-7 请求在线流媒体推送的返回指令过程请求部分的指令是需要到录像服务器部分和摄像头部分的，但是作为消息回馈的部分，在指令交互这一块只有CMS和Client之间的交互，通过这两个交互流程来完成了在实时摄像头流媒体数据的推送，代码实现请求过程如图4-8所示。 图4-8 请求在线流媒体推送的返回代码过程客户端请求摄像机实时视频，首先还是通过主函数模块来加载所有的函数模块，然后获取在线视频信息列表，对于客户端的实时摄像头视频数据通过当前流媒体视频数据的方法来处理这个请求。4.5 客户端退出系统的实现当客户端退出系统的时候会发送退出登录的实时请求，或者当客户端没有网络访问的时候也会有对应的失去连接请求，这种时候CMS会连接接口来判断和客户端之间的连接是否还在，如过连接失去了那么系统将自动关闭这条来连接，删除本次连接的会话数据。图4-9 客户端退出系统的指令过程当客户端退出系统后，CMS服务器会通过Redis服务器去数据库中查找退出的客户端的相关数据，然后将对应的数据记录删除。这样子本次退出连接的过程就完成了，下次客户端登录过来生成新的记录，这个在代码中的实现调用过程如4-10图所示。图4-10 客户端退出系统代码过程4.6服务器系统登出的实现当流媒体服务器系统的某一部分服务器出现问题的时候为了不影响整体系统的运行，需要为单个模块设计登出服务，这样子设计可以避免当某一模块的系统出项问题的时候影响到整个系统的运行。在这个部分的设计上系统要设置双向的登出操作，从CMS上退出其他系统的数据，以及在退出系统上退出当前的CMS数据。图4-11 服务器系统登出的过程各系统模块登出的过程和客户端登出的指令流程类似，但是执行的系统指令完全不一样，客户端是通过Http请求来确定是否在线，而服务器端是通过RSTP协议来实现信息交互，因此指令数据的传递是实时的，退出系统也是双向的，这个在代码中的实现调用过程如图4-12所示。 图4-12 服务器系统登出的代码过程服务器登出的过程是系统的生命周期中的一部分，在各服务器模块登录进CMS的时候会初始化各模块内容，初始化后会在CMS中存在session记录。当服务器模块退出后session会过期，会自动回收这部分的数据。5 系统测试5.1 测试的方法本次测试采用的是黑盒测试的方法，通过运行服务器，观察服务器在运行的过程中的数据输出情况来判断系统是否能够正常的运行，以及系统运行的结果是否服务系统的设计标准，测试本系统的过程中是依赖于整个的流媒体服务器来的。测试过程包括开启服务后对应的服务器是否注册到流媒体消息服务器中，在做数据请求的时候控制台打印的消息是否符合运行的标准。5.2 测试过程在本机中测试该项目，将整套系统相关的项目都编译成可执行的文件后。启动对应的服务然后连接电脑。开启数据库连接服务，测试数据库是否能正常启动。表5-1 开启数据库服务前置条件：服务器的配置信息已经配置完成测试方法：黑盒测试。输入数据：无。执行步骤：开启数据库服务。预期输出：数据库服务正常启动。实际结果：服务器启动。结论：测试成功。如图5-2显示的数据库服务器启动后的效果，数据库相关的服务开启等待着其他服务器的连接，在开启其他流媒体服务器后在此服务器上会有对应的数据流信息。图5-2 数据库服务测试数据库服务开启正常后，数据库服务器开始等待其他服务器的连接，这个时候开始去测试Camera服务器是否能够正常的启动成功。表5-3 开启数据库服务前置条件：Camera服务器的配置信息配置完成测试方法：黑盒测试。输入数据：无。执行步骤：开启Camera服务器服务。预期输出：Camera服务器服务正常启动。实际结果：Camera服务器正常的显示数据。结论：测试成功。Camera相关的服务器启动后，Camera心跳保活的数据如图5-2显示的数据，Camera服务器一直在显示外界的视频流媒体相关的消息。图5-4 Camera心跳保活显示数据库服务器和Camera服务器都正常启动后，准备测试CMS服务器，开启CMS服务器去观察服务器窗口的打印信息，看是否正常的连接到已开启的数据库服务器和Camera服务器表5-5 开启数据库服务前置条件：CMS服务器的配置信息配置完成测试方法：黑盒测试。输入数据：无。执行步骤：开启CMS服务器器服务。预期输出：CMS服务器服务正常启动。实际结果CMS服务器正常的显示数据。结论：测试成功。中心消息流媒体服务器的显示数据如图5-6显示，在该控制台上显示的数据正是本次测试的内容，分析图中的数据可以看出在整个系统的运行过程中，相关的服务器都和消息流媒体服务器有一个信息的交互。图5-6 消息服务器依次将数据库服务、Darwin服务、CMSS服务、录像服务、摄像服务开启后启动了整个系统的所有服务。然后打开手机的客户端，通过将客户端上的登录地址设定成服务器上同样的地址端口号设置成CMSS配置的端口，开始连接服务器。整个的请求过程中的消息交互都是在CMS中进行的，从系统进入就开始注册系统的消息，每一个请求都是通过CMS来做相应的处理，从数据流显示的数据来看，系统登录到CMS保持系统间的会话，系统中处理相应的请求都有对应的数据信息打印出来。图5-7 消息服务器5.3 测试总结通过测试过程中的数据分析本次测试过程从客户端到服务器，从服务器到客户端这几个交互过程都是如此的执行的。客户端像服务器端请求摄像头数据，消息管理器处理该请求，像摄像头相关的服务发送了请求指令，摄像头服务将流媒体数据推送给Darwin,Darwin将流媒体数据推送到客户端上，客户端解析了该流媒体数据后显示出了视频数据，这整一个交互过程的信息指令都通过消息服务器处理，在整个的信息的交互过程中，CMS都是在对相应的数据进行着处理，每一个请求的数据也都是打印在控制台中。显示的数据也都是和系统设计之初定义的数据是一致的，对整个测试过程中的数据分析最后可以得出的结论是，本系统的设计是符合Apple Darwin的流媒体的设计标准的。参考文献1 杨海澜流媒体系统中的几项关键技术分析及应用J武汉交通职业学院学报，2014：132-1502 董科军，南凯，阎保平一种可扩展的集群流媒体服务器J计算机工程与应用，2015：15-253 丁杰，潘晨光，田源基于crtmpserver的手机直播系统J计算机工程与设计，2014：32-104 姜浩然，徐林基于RTMP的流媒体服务器的研究J计算机与数字工程，2015：132-1505 史红周，黄晁一种基于MP4文件的视频流关键帧索引播放方法J微电子学与计算机，20156 李新乐，苏鸿根流媒体搜索和发布技术在移动设备上的应用J计算机工程与设计，20147 茅炎菲，黄忠东基于RTSP协议网络监控系统的研究与实现J计算机工程与设计，20158 罗大晖，陈娟基于HTML5的Web离线应用研究与实现J计算机应用与软件，2015：2-89 李校林，刘海波，张杰RTP/RTCP，RTSP在无线视频监控系统的设计与实现J电视技术，2015：89-9210 韦崇岭，裴海龙基于无人机平台H264视频传输系统的设计与实现J计算机测量与控制，201