基于apple-darwin的流媒體消息管理服務(wù)器的設(shè)計與實現(xiàn)

1、<p><b>　　本科畢業(yè)論文</b></p><p><b>　　中國·武漢</b></p><p><b>　　二〇一七年五月</b></p><p>　題 目基于Apple Darwin的流媒體消息管理服務(wù)器的設(shè)計與實現(xiàn)</p><p>　De

2、sign and Implementation of Streaming Media Message Management Server Based On Apple Darwin</p><p>　姓 名學(xué) 號</p><p>　專 業(yè)計算機科學(xué)與技術(shù)</p><p>　指導(dǎo)教師職 稱講師/碩士</p><p>　

3、　分類號 密級</p><p>　　華中農(nóng)業(yè)大學(xué)楚天學(xué)院本科畢業(yè)論文</p><p>　　基于Apple Darwin的流媒體消息管理服務(wù)器的設(shè)計與實現(xiàn)</p><p>　　Design and Implementation of Streaming

4、 Media Message Management Server Based on Apple Darwin</p><p>　　華中農(nóng)業(yè)大學(xué)楚天學(xué)院</p><p><b>　　二〇一七年五月</b></p><p><b>　　目 錄</b></p><p><b>　　摘要I<

5、;/b></p><p><b>　　關(guān)鍵詞I</b></p><p>　　AbstractI</p><p>　　Key wordsI</p><p>　　1 系統(tǒng)的可行性研究概述1</p><p>　　1.1 課題背景及研究現(xiàn)狀1</p><p>　　1

6、.2 課題意義1</p><p>　　1.3 課題目標1</p><p>　　2 系統(tǒng)相關(guān)技術(shù)與協(xié)議1</p><p>　　2.1 主體框架2</p><p>　　2.2 RTSP協(xié)議3</p><p>　　2.3 SDP協(xié)議3</p><p>　　2.4 RTP協(xié)議3</p

7、><p>　　2.5 RTCP控制協(xié)議4</p><p>　　3 流媒體消息管理服務(wù)器設(shè)計4</p><p>　　3.1 流媒體消息服務(wù)器的系統(tǒng)框架4</p><p>　　3.2 客戶端請求到服務(wù)器的過程5</p><p>　　3.3 客戶端請求在線流媒體信息的過程7</p><p>　　

8、3.4 客戶端請求攝像頭的實時視頻信息的過程8</p><p>　　3.5 Camera錄像的過程9</p><p>　　3.6 CMS服務(wù)器的接口設(shè)計10</p><p>　　4 流媒體消息服務(wù)器實現(xiàn)12</p><p>　　4.1 流媒體交互中的消息傳遞設(shè)計12</p><p>　　4.2 客戶端登錄到服

9、務(wù)器的實現(xiàn)過程13</p><p>　　4.3 客戶端請求在線流媒體信息的實現(xiàn)過程14</p><p>　　4.4 客戶端請求通道攝像機實時碼流推送16</p><p>　　4.5 客戶端退出系統(tǒng)的實現(xiàn)17</p><p>　　4.6服務(wù)器系統(tǒng)登出的實現(xiàn)18</p><p><b>　　5 系統(tǒng)測試

10、20</b></p><p>　　5.1 測試的方法20</p><p>　　5.2 測試過程20</p><p>　　5.3 測試總結(jié)22</p><p><b>　　參考文獻23</b></p><p><b>　　致謝24</b></p&g

11、t;<p><b>　　摘 要</b></p><p>　　流媒體消息管理服務(wù)器在整個流媒體服務(wù)器中作為全局交互的角色，在服務(wù)器項目中負責全局的消息管理，用來處理所有的相關(guān)的業(yè)務(wù)請求。該服務(wù)器是基于Darwin的基礎(chǔ)上開發(fā)的，它的作用是分離Darwin中消息處理部分，讓Darwin將主要的業(yè)務(wù)放在流媒體的處理上。流媒體消息管理服務(wù)器是用來處理用戶的請求以及在整個流媒體服務(wù)器中各

12、功能部分的交互部分。開發(fā)基于Darwin的流媒體服務(wù)器使用VS2008作為開發(fā)工具，整個服務(wù)器的開發(fā)過程主要的解決方案是處理各服務(wù)器部分的信息交互部分，對于客戶端使用HTTP協(xié)議來進行信息交互，服務(wù)器之間使用RSTP協(xié)議來進行信息交互。</p><p><b>　　關(guān)鍵詞 </b></p><p>　　流媒體；消息管理服務(wù)器；消息交互；設(shè)備接入；</p>

13、<p><b>　　Abstract</b></p><p>　　Streaming media message management server as a global interactive role in the streaming media server,that is responsible for global in the whole project,where

14、 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 st

15、reaming media. The streaming media management server is mainly used to process the user's request and the request interact</p><p><b>　　Key words</b></p><p>　　Streaming; Media Mes

16、sage Management Server; Message Interaction; Device Access;</p><p>　　1 系統(tǒng)的可行性研究概述</p><p>　　1.1 課題背景及研究現(xiàn)狀</p><p>　　隨著無線網(wǎng)絡(luò)的飛速發(fā)展和技術(shù)的不斷更新，互聯(lián)網(wǎng)已經(jīng)普及到每一個普通的家庭。Internet的基礎(chǔ)架構(gòu)慢慢趨于完善，對于網(wǎng)絡(luò)上信息的交互

17、結(jié)構(gòu)已經(jīng)發(fā)生了本質(zhì)上的改變。從最開始的基本的文字信息和圖片信息到了現(xiàn)在大容量、高信息量的流媒體信息。已經(jīng)不是僅僅只有圖片信息就能滿足用戶的需求了，而現(xiàn)在的電子競技行業(yè)也是十分火熱，各大賽事直播也是一個非常火熱場景。在當下這個人們需求大量視頻數(shù)據(jù)傳播的背景下一個好的穩(wěn)定的快速的流媒體服務(wù)器是十分有必要的。人們迫切的希望看到實時的場景直播，對于直播的畫面也是有一個高清的要求。在當前的流媒體領(lǐng)域，有以下三種占著主導(dǎo)地位它們分別是Apple公司

18、的Quick Time、Microsoft公司的Media Server以及Real公司的Real System。</p><p>　　其中Apple Darwin是蘋果公司開源的一個非常優(yōu)秀的流媒體服務(wù)器。而本文就是基于該服務(wù)器的基礎(chǔ)開發(fā)的關(guān)于在流媒體服務(wù)器運行過程中的所有的關(guān)于數(shù)據(jù)訪問部分的服務(wù)器器設(shè)計，是整個流媒體服務(wù)器中關(guān)于消息的服務(wù)器。對于一個流媒體服務(wù)器而言，主要的實現(xiàn)部分是流媒體服務(wù)器來實現(xiàn)流媒體數(shù)

19、據(jù)的推送。而對于信息交互而言蘋果開源的服務(wù)器是提供Darwin來處理這個過程的。本文是基于Darwin的基礎(chǔ)來開發(fā)，所做的內(nèi)容主要是將消息處理部分相關(guān)的內(nèi)容獨立出來，通過消息服務(wù)器來處理整個流媒體服務(wù)器中的信息交互部分，而Darwin主要去處理流媒體信息的推送相關(guān)的部分。將消息處理的部分獨立出來提高整個流媒體的服務(wù)器的效率性，各個模塊由對應(yīng)的部分去處理，各模塊獨立又相互交叉的去處理業(yè)務(wù)。</p><p><

20、b>　　1.2 課題意義</b></p><p>　　在實際應(yīng)用中，用戶對于通過互聯(lián)網(wǎng)獲取視頻音頻的消息，于是流媒體應(yīng)運而生，滿足了用戶對于網(wǎng)上高質(zhì)量多媒體信息的需要。而隨著技術(shù)的跟新與迭代，人們對現(xiàn)階段的流媒體有了新的要求，想要有更好的用戶體驗，能夠?qū)崟r的無延遲的去觀看直播視頻。通過網(wǎng)絡(luò)實時的去監(jiān)控部署的攝像頭下的視頻數(shù)據(jù)也是一個在原有的基礎(chǔ)上的更好的體驗，能夠?qū)崟r的觀察家中的狀況，或者監(jiān)控某

21、一塊地域的實時情況。而這些技術(shù)也將廣泛的應(yīng)用于多媒體的新聞在線、直播、遠程教育、視頻點播、實時視頻回憶等廣泛的方面。</p><p><b>　　1.3 課題目標</b></p><p>　　本課題的目標為在一個流媒體服務(wù)器中實現(xiàn)一個中心管理服務(wù)器（CMS），該中心管理服務(wù)器用于實現(xiàn)整個流媒體服務(wù)器中的信息交互和視頻信息推送。當客戶端發(fā)送數(shù)據(jù)請求時，中心管理服務(wù)器服務(wù)

22、處理該用戶請求，并將該請求發(fā)送到流媒體服務(wù)器中，待流媒體服務(wù)器對該請求做出了響應(yīng)后處理該響應(yīng)結(jié)果并反饋給客戶端?？蛻舳嗽诎l(fā)送錄像請求的時候，中心管理服務(wù)器處理該用戶請求，并將該請求發(fā)送到Camera錄像相關(guān)的服務(wù)上面，Camera錄像服務(wù)去處理該錄像的請求。中心管理服務(wù)器負責處理整個請求的交互過程。在整個流媒體服務(wù)處理的相關(guān)交互過程中都會設(shè)計到信息的交互和回饋處理，中心管理服務(wù)器的作用就相當于中國的古老職業(yè)郵差，它負責傳遞獲取這些信息，

23、然后解析這些信息并將它推送到相應(yīng)的處理模塊當中。</p><p>　　2 系統(tǒng)相關(guān)技術(shù)與協(xié)議</p><p>　　Darwin Streaming Server簡稱DSS，DSS作為Apple公司提供的開源實時流媒體播放服務(wù)器程序。整個服務(wù)器使用C++編寫，在設(shè)計上遵循高性能、簡單、模塊化等程序設(shè)計原則，在使用上具有高效性和可擴展性。為了提高流媒體服務(wù)器處理請求的效率，消息管理服務(wù)器正式基

24、于DSS來單獨分離出消息處理模塊用于接收和處理服務(wù)器系統(tǒng)之間的請求，讓DSS將主要的功能用于做流媒體消息推流上。各應(yīng)用部分之間的請求通過消息流媒體服務(wù)器器處理之后，將信息指令傳遞給DSS。</p><p><b>　　2.1 主體框架</b></p><p>　　Darwin流媒體服務(wù)器是由一個父進程構(gòu)成的，在該父進程中分叉出來的一個子進程，作為服務(wù)器的核心服務(wù)器。運

25、行中父進程會等待子進程，當子進程發(fā)生退出錯誤的時候，父進程會分叉出新的子進程。分叉出來的子進程的作用是作為充當網(wǎng)絡(luò)客戶和服務(wù)器模塊的接口，對于網(wǎng)絡(luò)客戶通過RTP和RTSP協(xié)議來發(fā)送請求信息和接收響應(yīng)信息，而對于服務(wù)器模塊，它是負責處理各種請求和向客戶端發(fā)送信息數(shù)據(jù)包。核心服務(wù)器是通過創(chuàng)建幾種類型的服務(wù)線程來完成自己各模塊相關(guān)的工作，具體如下：</p><p>　　服務(wù)器本身擁有自己的主線程（Main Thread

26、）。這個主線程主要負責檢查當前服務(wù)器是否需要關(guān)閉，記錄當前狀態(tài)信息，或者打印當前統(tǒng)計信息?？臻e任務(wù)線程（Idle Task Thread）?？臻e任務(wù)線程主要管理一個周期性的任務(wù)隊列。這種任務(wù)隊列有兩種類型：套接口任務(wù)和事件線程（Event Thread）。事件線程主要是負責偵聽套接口的任務(wù)事件，比如收到了RTSP請求或者RTP數(shù)據(jù)包，之后把事件傳遞到任務(wù)線程中處理。服務(wù)器中會存在一個或者多個處理任務(wù)的線程。任務(wù)線程主要是負責從事件線程中

27、去接收RTSP和RTP請求，然后把接收到的請求傳遞到恰當?shù)姆?wù)器模塊去做對應(yīng)的處理，然后把數(shù)據(jù)包反饋給客戶端。在缺省情況下，核心服務(wù)器會為每一個處理器去創(chuàng)建一個任務(wù)線程。</p><p>　　圖2-1總結(jié)了客戶端，核心服務(wù)器的線程，和服務(wù)器模塊之間的關(guān)系。</p><p>　　圖2-1 Darwin服務(wù)器架構(gòu)</p><p>　　由于服務(wù)器中的線程在處理上是異步的，

28、所以對于不同的事件需要提供一個對應(yīng)的通訊機制。例如當某個用于處理RTSP連接的套接口得到請求數(shù)據(jù)的時候，需要去通知某些組件，來處理數(shù)據(jù)，而任務(wù)對象就是用來處理這種通訊的機制。</p><p>　　對于每個任務(wù)對象都存在兩個主要的通訊方法Signal和Run。服務(wù)器通過調(diào)用Signal方法來傳遞Task對象給對象，對于Run方法是用來指定處理任務(wù)的對象的。每個Task對象的處理方法都是通過用小的非阻塞的時間片段來完

29、成服務(wù)器的功能。在Run函數(shù)的內(nèi)部，Task對象通過調(diào)用GetEvents函數(shù)來接收當前的和先前已經(jīng)用信號通知過的事件，并自動使該事件退出隊列。Run函數(shù)是永遠不可重入的，如果一個Task對象在其Run函數(shù)中調(diào)用GetEvents函數(shù)，然后在Run函數(shù)完成之前又發(fā)出信號，則該Run函數(shù)只有在當前的函數(shù)實例退出之后，才能（因為那個新的事件）再次被調(diào)用。事實上，Task對象的Run函數(shù)會被反復(fù)調(diào)用，直到該對象的所有事件全部被GetEvent

30、s函數(shù)清除掉為止。</p><p>　　這個事件觸發(fā)任務(wù)的核心概念被集成到幾乎每一個流媒體服務(wù)器的子系統(tǒng)中。舉例來說，一個Task對象可能和一個套接口Socket對象相關(guān)聯(lián)。如果Socket對象得到一個事件通過select通知，或者通過Mac OS X的時間隊列，則相應(yīng)的Task對象就會得到信號通知。在這種情況下，Run函數(shù)的函數(shù)體中就會包含相應(yīng)的代碼，來處理在該Socket對象上接收到的任何事件。Task對象使

31、得流媒體服務(wù)器用單獨一個線程來運行所有連接的做法成為可能，這正是流媒體服務(wù)器在單處理器系統(tǒng)上的缺省設(shè)置。</p><p>　　Darwin流媒體服務(wù)器使用模塊來相應(yīng)各種請求完成請求任務(wù)，主要有三種模塊內(nèi)容管理模塊、服務(wù)器支持模塊、訪問控制模塊。所有的信息交互功能和流媒體消息推送模塊都是在Darwin上完成的，本系統(tǒng)的設(shè)計是基于Darwin服務(wù)器的。其核心的功能是將消息處理的部分從Darwin服務(wù)器中分離出來，所以

32、系統(tǒng)設(shè)計之初通過分析Darwin服務(wù)器對于其模塊分類分割之后。流媒體消息服務(wù)器主要是將內(nèi)容管理模塊分離出來做單獨的數(shù)據(jù)交互處理。</p><p>　　內(nèi)容消息模塊是負責管理和媒體源相關(guān)的RSTP請求和相應(yīng)，所以流媒體消息管理服務(wù)器的主要功能就是用于處理消息交互的。消息處理后和Darwin進行交互，將對應(yīng)的請求發(fā)送給Darwin，然后讓Darwin去處理對用的請求內(nèi)容。</p><p>　　

33、2.2 RTSP協(xié)議</p><p>　　作為一個應(yīng)用層協(xié)議，RTSP提供了對外可供擴展的應(yīng)用框架，這個意義在于使得實時流媒體的數(shù)據(jù)變得可控，從而讓點播變得可行。總體來說，RTSP協(xié)議是一個流媒體表示層的協(xié)議，主要是用于控制具有實時特性的數(shù)據(jù)，但是它本身是不傳輸數(shù)據(jù)的，而是必須通過依賴于下層傳輸協(xié)議所提供服務(wù)來傳遞數(shù)據(jù)。RTSP協(xié)議可以對流媒體服務(wù)提供播放、暫停、快進等相關(guān)的數(shù)據(jù)操作，它主要用于定義具體的控制消息

34、、操作方法、狀態(tài)碼等，同時還定義了和RTP之間的數(shù)據(jù)交互。RTSP協(xié)議在制定時較多地參考了HTTP1.1協(xié)議，甚至許多的描述和HTTP/1.1是完全相同的。RTSP之所以特意的去使用與HTTP/1.1類似的語法和操作，在很大程度上是為了考慮兼容現(xiàn)有的Web基礎(chǔ)結(jié)構(gòu)。雖然RTSP服務(wù)器同樣也使用標識符來區(qū)別每個會話流連接的Session，但是RTSP連接并不會因此綁定到傳輸層的連接，也就是說對于整個的RTSP在連接期間，RTSP用戶是可以

35、打開或者關(guān)閉多個對RTSP服務(wù)器的可靠傳輸連接來發(fā)出RTSP請求。同時，RTSP協(xié)議也是基于面向無連接的傳輸協(xié)議的如UDP等。</p><p>　　一次基本的RTSP連接操作過程是，首先，客戶端會發(fā)送一個RTSP描述命令DESCRIBE來連接到流服務(wù)器。在流服務(wù)器中通過一個SDP來進行描述反饋，描述反饋包含流數(shù)量、媒體類型等數(shù)據(jù)信息。在客戶端通過分析該SDP，并為會話中的每一個流發(fā)送一個SETUP建立的RTSP流

36、命令，RTSP流命令會傳遞給服務(wù)器，客戶端用來接收媒體數(shù)據(jù)的端口。流媒體連接建立成功后，客戶端會發(fā)送一個播放請求命令PLAY，服務(wù)器就會開始在UDP上傳送媒體流RTP包反饋給客戶端。 在播放的過程中客戶端還可以向服務(wù)器發(fā)送相應(yīng)的命令來控制視頻流的快進、快退和暫停等。最后，客戶端通過發(fā)送一個終止命令TERADOWN來結(jié)束本次的流媒體會話。</p><p><b>　　2.3 SDP協(xié)議</b>

37、</p><p>　　SDP傳遞著媒體流信息，接收者可以解析傳入的SDP數(shù)據(jù)，從而知道發(fā)送者的基本信息。SDP基本上在Internet上工作。SDP定義了會話描述的統(tǒng)一格式，但不會定義多播地址的分配和SDP消息的傳輸方式，也不支持媒體編碼方案的協(xié)商，這些功能均由下層傳送協(xié)議完成。SDP完全是一種會話描述格式,它不屬于任何傳輸協(xié)議,它只用于使用對應(yīng)的傳輸協(xié)議，這些協(xié)議包括SAP會話通知協(xié)議、RTSP實時流協(xié)議、MI

38、ME電子郵件的擴展協(xié)議以及HTTP超文本傳輸協(xié)議。由于SDP協(xié)議本身是基于文本的協(xié)議，因此SDP協(xié)議的可擴展性是比較強的，在很多場景下都會廣泛的用到SDP協(xié)議。SDP本身是不支持會話內(nèi)容和媒體編碼的協(xié)商，所以在流媒體中媒體協(xié)商這一塊要用RTSP來實現(xiàn)。SDP 完全是一種會話描述格式,它不屬于傳輸協(xié)議,它只使用不同的適當?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議SAP、會話初始協(xié)議SIP、實時流協(xié)議RTSP、MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)

39、議HTTP。SDP協(xié)議是也是基于文本的協(xié)議，這樣就能保證協(xié)議的可擴展性比較強，這樣就使其具有廣泛的應(yīng)用范圍。SDP 不支持會話內(nèi)容或媒體編碼的協(xié)商，所以在流媒體中只用</p><p><b>　　2.4 RTP協(xié)議</b></p><p>　　RTP數(shù)據(jù)協(xié)議負責對流媒體數(shù)據(jù)進行封包并實現(xiàn)媒體流的實時傳輸，每一個RTP數(shù)據(jù)報都由頭部Header和負載Payload兩個部

40、分組成，其中頭部前12個字節(jié)的含義是固定的，而負載則可以是音頻或者視頻數(shù)據(jù)。其中比較重要的幾個域及其意義，CSRC記數(shù)CC表示CSRC標識的數(shù)目。CSRC標識緊跟在RTP固定頭部之后，用來表示RTP數(shù)據(jù)報的來源，RTP協(xié)議允許在同一個會話中存在多個數(shù)據(jù)源，它們可以通過RTP混合器合并為一個數(shù)據(jù)源。例如，可以產(chǎn)生一個CSRC列表來表示一個電話會議，該會議通過一個RTP混合器將所有講話者的語音數(shù)據(jù)組合為一個RTP數(shù)據(jù)源。負載類型PT標明RT

41、P負載的格式，包括所采用的編碼算法、采樣頻率、承載通道等。例如，類型2表明該RTP數(shù)據(jù)包中承載的是用ITU G.721算法編碼的語音數(shù)據(jù)，采樣頻率為8000Hz，并且采用單聲道。序列號用來為接收方提供探測數(shù)據(jù)丟失的方法，但如何處理丟失的數(shù)據(jù)則是應(yīng)用程序自己的事情，</p><p>　　RTP協(xié)議本身并不負責數(shù)據(jù)的重傳。時間戳記錄了負載中第一個字節(jié)的采樣時間，接收方能夠時間戳能夠確定數(shù)據(jù)的到達是否受到了延遲抖動的影

42、響，但具體如何來補償延遲抖動則是應(yīng)用程序自己的事情。從RTP數(shù)據(jù)報的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數(shù)據(jù)等信息，這些都為實時的流媒體傳輸提供了相應(yīng)的基礎(chǔ)。RTP協(xié)議的目的是提供實時數(shù)據(jù)如交互式的音頻和視頻的端到端傳輸服務(wù)，因此在RTP中沒有連接的概念，它可以建立在底層的面向連接或面向非連接的傳輸協(xié)議之上。RTP也不依賴于特別的網(wǎng)絡(luò)地址格式，而僅僅只需要底層傳輸協(xié)議支持組幀F(xiàn)raming和分段Seg

43、mentation就足夠了。另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協(xié)議或者應(yīng)用程序自己來保證。在典型的應(yīng)用場合下，RTP一般是在傳輸協(xié)議之上作為應(yīng)用程序的一部分加以實現(xiàn)的。</p><p>　　2.5 RTCP控制協(xié)議</p><p>　　RTCP控制協(xié)議本身不單獨使用，需要和RTP協(xié)議一起使用，當在應(yīng)用程序中開啟了RPT回話時，會同時占用兩個對應(yīng)的端口，這兩個端口對應(yīng)RTP

44、和PTCR的連接接口。RTP協(xié)議并不能為按序傳輸數(shù)據(jù)包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會采用與RTP相同的分發(fā)機制，向會話中的所有成員周期性地發(fā)送控制信息，應(yīng)用程序通過接收這些數(shù)據(jù)，從數(shù)據(jù)中讀取相關(guān)數(shù)據(jù)，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息。 </p><p>　　RTCP協(xié)議通過不同的RTCP數(shù)據(jù)報來傳遞，主要有幾種類型。SR發(fā)送端報告，發(fā)出RTP數(shù)據(jù)報的應(yīng)用

45、程序或者終端稱為發(fā)送端，發(fā)送端同時也可以是接收端。RR接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報的應(yīng)用程序或者終端。SDES源描述，主要功能是作為會話成員有關(guān)標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。BYE通知離開。主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。</p><p>　　3 流媒體消息管理服務(wù)器設(shè)計</p

46、><p>　　3.1 流媒體消息服務(wù)器的系統(tǒng)框架</p><p>　　流媒體服務(wù)器作為整個系統(tǒng)的交互部分負責處理來自設(shè)備的注冊連接和其他的各個服務(wù)器節(jié)點的連接，流媒體服務(wù)器Darwin的接入請求、錄像管理服務(wù)的接入請求、來自于客戶端的接入請求。對于所有設(shè)備關(guān)于連接的維護和管理或控制操作命令的發(fā)送，設(shè)備信息的上報解析來自客戶端的請求都是在中心管理服務(wù)器上處理的。圖3-1總結(jié)了整個的請求流程。&l

47、t;/p><p>　　圖3-1 流媒體服務(wù)器的系統(tǒng)框架圖</p><p>　　這是整個服務(wù)器中的通訊流程的系統(tǒng)設(shè)計，其中消息交互如圖3-2所示。</p><p>　　圖3-2 流媒體服務(wù)器的消息傳遞圖</p><p>　　從消息流程圖中可以看出，對于整個系統(tǒng)而言，在設(shè)計上是功能分離的，每一個功能部分都是由對于的系統(tǒng)服務(wù)來執(zhí)行。這樣子進行業(yè)務(wù)分離對

48、于系統(tǒng)的健壯性而言是很有必要的，可以讓服務(wù)器有一個更大的數(shù)據(jù)負載量。</p><p>　　3.2 客戶端請求到服務(wù)器的過程</p><p>　　從流媒體服務(wù)器的系統(tǒng)框架圖中可以看出，對于整個的流媒體服務(wù)器而言是分為很多的服務(wù)器模塊的。這樣子分化模塊也是為了將服務(wù)器處理的功能模塊抽取出來，每一個服務(wù)器做專門的業(yè)務(wù)服務(wù)，這樣子對整個流媒體服務(wù)器而言可以很大程度的提高服務(wù)的處理業(yè)務(wù)和負載能力。對

49、整個流媒體服務(wù)器而言，中心管理服務(wù)器是處理整個服務(wù)器體系中信息流的核心組件?？梢哉f整個系統(tǒng)的交互性都是在這里完成的，如過這個地方的業(yè)務(wù)出現(xiàn)了問題那么整個流媒體系統(tǒng)是無法正常運轉(zhuǎn)的。所以在設(shè)計過程中，這一塊的交互性顯然是重中之重，在設(shè)計的過程中，各系統(tǒng)的交互設(shè)計是非常的重要的。</p><p>　　從服務(wù)器的開啟來分析整體的設(shè)計流程。如圖3-3所示顯示的是整個流媒體服務(wù)器開啟的時候所需要做的工作。Darwin流媒體

50、服務(wù)器開啟，CMS服務(wù)器開啟，RMS服務(wù)器開啟，攝像頭相關(guān)的服務(wù)器開啟，數(shù)據(jù)庫Redis相關(guān)的服務(wù)器也啟動，這些服務(wù)器在一個網(wǎng)絡(luò)端中啟動，所以在通信上是沒有什么問題的。服務(wù)器都開啟成功后，服務(wù)器之間必然是會有一定的數(shù)據(jù)交互過程。CMS服務(wù)器將其他的功能服務(wù)器的消息記錄到本機中，關(guān)于其他服務(wù)器的數(shù)據(jù)是存儲到Redis中的。在客戶端發(fā)起來請求后，會去數(shù)據(jù)庫中找處理對應(yīng)請求的服務(wù)器模塊，通過之前存儲的數(shù)據(jù)去找到相應(yīng)的處理模塊，通過發(fā)送交互請求

51、來等待對應(yīng)的服務(wù)器返回消息，交互連同后開始業(yè)務(wù)處理的信息指令傳遞。</p><p>　　圖3-3 服務(wù)器開器處理過程圖</p><p>　　服務(wù)器正常開啟成功后級開始進入到，處理功能交互的過程了。各服務(wù)器將數(shù)據(jù)注冊到了消息服務(wù)器中，也通過請求進行了系統(tǒng)交互。再設(shè)計過程中將服務(wù)器都設(shè)計在同一網(wǎng)絡(luò)段保重數(shù)據(jù)交互的通透性，數(shù)據(jù)訪問交互的過程如圖3-4所示。</p><p>

52、;　　圖3-4 服務(wù)器數(shù)據(jù)交互過程</p><p>　　CMS數(shù)據(jù)庫和數(shù)據(jù)庫之間的處理流程是雙向的，發(fā)送請求后能夠很快的從數(shù)據(jù)庫中獲取到對應(yīng)的數(shù)據(jù)。使用的數(shù)據(jù)庫是Redis，這是一個采用鍵值對存儲的數(shù)據(jù)，所以對應(yīng)數(shù)據(jù)的索引是非常的迅速的，因此對應(yīng)數(shù)據(jù)的交互而言體驗感是很強的，不存在卡頓和延遲。</p><p>　　服務(wù)器啟動連接完畢后開始功能方面的設(shè)計，圖3-5是客戶端登錄到數(shù)據(jù)的流程，在

53、客戶端登錄到服務(wù)器時，客戶端向流媒體消息服務(wù)器發(fā)送一個登錄請求。流媒體消息服務(wù)器獲取到該請求后，解析該請求中的信息，獲取登錄的客戶端的用戶名、密碼、端口號以及IP地址。然后向Redis數(shù)據(jù)庫請求數(shù)據(jù)去驗證是否包含了當前的用戶信息，如過沒有就創(chuàng)建新的用戶信息，并將結(jié)果反饋給客戶端?？蛻舳私馕霰敬蔚姆答佇畔ⅲ卿洺晒M入主功能界面。</p><p><b>　　圖3-5 登錄流程</b><

54、/p><p>　　3.3 客戶端請求在線流媒體信息的過程</p><p>　　客戶端登錄完成后會向流媒體消息服務(wù)器發(fā)送一個獲取當前服務(wù)器在線視頻數(shù)據(jù)的列表。流媒體消息服務(wù)器獲取到該請求后，將請求的數(shù)據(jù)封裝成一條指令然后發(fā)送到Darwin服務(wù)器上去請求在線視頻信息，Darwin處理該請求后會反饋一條處理信息給流媒體消息服務(wù)器，流媒體消息服務(wù)器將該反饋發(fā)送給客戶端。同時Darwin將在線視頻的數(shù)據(jù)

55、推送給客戶端，這樣子就完成了一次視頻請求的過程。在這個過程中客戶端接收了來自服務(wù)器的視頻數(shù)據(jù)，客戶端點開視頻數(shù)據(jù)可以開始異步的去加載視頻信息觀看，圖3-6顯示的是該請求流程。</p><p>　　圖3-6 獲取在線視頻列表</p><p>　　在這個請求的交互過程中存在的流消息交互過程如圖3-7所示，消息交互都是雙向的，在交互過程中客戶端使用的是HTTP請求到CMS服務(wù)器這段，而服務(wù)器之間

56、的消息交互采用的是RTSP協(xié)議來保證協(xié)力的聯(lián)通性。</p><p>　　圖3-7 獲取在線視頻列表信息交互過程</p><p>　　這個交互過程中，CMS只負責信息的傳遞，對于視頻流相關(guān)的信息是不通過CMS作為傳遞通道的，這個處理過程只包含著信息的交互過程。對這個請求過程中請求封裝的消息只是交互雙發(fā)的位置以及對應(yīng)的協(xié)議信息對于具體的流媒體信息是通過專門的流媒體通道去進行流媒體數(shù)據(jù)傳輸?shù)模@

57、個傳輸過程是Darwin服務(wù)器來負責的，CMS服務(wù)器主要是處理消息請求，對流媒體請求只負責處理相關(guān)的命令請求過程。</p><p>　　3.4 客戶端請求攝像頭的實時視頻信息的過程</p><p>　　客戶端請求實時的攝像頭視頻信息，客戶端向流媒體消息服務(wù)器發(fā)送一個請求信息，流媒體消息服務(wù)器解析該請求。將該請求信息發(fā)送給錄像管理服務(wù)器請求攝像頭的視頻信息，錄像管理服務(wù)器對該請求做出處理。錄

58、像管理服務(wù)器給攝像頭發(fā)送錄像請求，攝像頭開始將當前鏡頭下的視頻信息推送到Darwin服務(wù)器上，Darwin服務(wù)器獲取到了當前的實時信息后將該視頻信息推送到客戶端上。Darwin對該推送過程反饋給流媒體消息服務(wù)器，流媒體消息服務(wù)器將該反饋信息發(fā)送給客戶端?？蛻舳双@取到反饋信息和推送流視頻后在本地去解析當前的視頻流信息。對于視頻流的數(shù)據(jù)解析是通過專門的數(shù)據(jù)解析算法來實現(xiàn)的，這部分的工作是在客戶端上面去實現(xiàn)的，當CMS處理完這個請求后，Dar

59、win服務(wù)器和客戶但直接就有了一個流媒體的信息交互通道，視頻流信息到了客戶端后，對數(shù)據(jù)決心解析，最后在客戶端上面就可以顯示當前的實時視頻信息，圖3-8顯示的是該請求流程。</p><p>　　圖3-8 獲取實時攝像信息</p><p>　　這一個請求過程是一個很復(fù)雜的信息交過程，這個請求過程中的信息處理部分包含了整個系統(tǒng)的所有的處理模塊，所以在處理信息的交互過程中要保證信息傳遞的順序性和實

60、時性。只有這樣子才能保證在信息處理的交互過程中。請求指令都有續(xù)的執(zhí)行了，這樣子才能得到系統(tǒng)設(shè)計所需要的效果，整個過程中的信息交互過程如圖3-9所示。</p><p>　　圖3-9 實時視頻的信息交互過程</p><p>　　3.5 Camera錄像的過程</p><p>　　對應(yīng)攝像頭的攝像過程這一系統(tǒng)流程中的信息交互，如圖3-10所示是整個交互過程中的信息流程。&

61、lt;/p><p>　　圖3-10 錄像的信息交互過程</p><p>　　客戶端請求錄制視屏，消息管理服務(wù)器獲取到該請求后將請求消息發(fā)送給Camera，攝像頭開始錄像，同時消息管理器也將該請求消息發(fā)送給力Darwin服務(wù)器和錄像管理服務(wù)器。錄像管理服務(wù)器負責在視頻錄制過程中，Camera將視頻流推送給Darwin后，錄像管理服務(wù)器獲取該推送流數(shù)據(jù)存儲到本地，同時將該存儲消息備案到消息管理服務(wù)

62、器中。消息管理服務(wù)器將該條錄像消息反饋給客戶端方便查詢，圖3-11顯示的是該請求流程。</p><p>　　圖3-11 Camera錄像過程</p><p>　　3.6 CMS服務(wù)器的接口設(shè)計</p><p>　　作為與外接通信的接口，在設(shè)計服務(wù)器接口的時候需要考慮到負載量的問題，如果有大量的客戶端接入過來，服務(wù)器這邊如何去處理多設(shè)備。由于服務(wù)器的設(shè)計是多線程異步加

63、載的，所以在設(shè)計的時候可以考慮提供盡可能多的接入口，而對于數(shù)據(jù)返回的接口應(yīng)該減少數(shù)量，這樣子可以同時加載盡可能多的客戶端而不會出現(xiàn)長時間等待的問題，CMS接口的設(shè)計如圖3-12所示。</p><p>　　圖3-12 客戶端接入口設(shè)計</p><p>　　從這個設(shè)計圖中可以看出，對與CMS服務(wù)器而言提供大量的接入口，而反饋消息的接口設(shè)置的相對少一些，這樣子可以去處理大量的客戶端接入。在系統(tǒng)內(nèi)

64、部請求完成后將請求的結(jié)果返回回去，這樣的過程是異步的所以不會造成線程堵塞，因此對于將回饋的接口設(shè)計的少一些是不會對系統(tǒng)造成影響的。上面介紹的是客戶端和服務(wù)器之間的連接接口，下圖3-13介紹的是服務(wù)器系統(tǒng)內(nèi)部之間的接口設(shè)計。</p><p>　　圖3-13 系統(tǒng)接入口設(shè)計</p><p>　　對于與系統(tǒng)之間的接口，必須是一對一對應(yīng)的，因為使用的協(xié)議是RSTP協(xié)議，作為一種實時的協(xié)議不同于和客

65、戶端連接的接口需要實時連通。作為系統(tǒng)之間的交互，不僅僅只是通過接口連接成功就可以了，還需要將連接上來的服務(wù)器數(shù)據(jù)存儲到數(shù)據(jù)庫當中，因此需要設(shè)計和數(shù)據(jù)庫交互的接口，在這個設(shè)計上是需要用到數(shù)據(jù)庫服務(wù)來完成這對接的。</p><p>　　圖3-14 數(shù)據(jù)庫接口設(shè)計</p><p>　　對于數(shù)據(jù)庫而言，接口在在設(shè)計的時候考慮的是唯一性，單個負載的系統(tǒng)在連接的時候只考慮去開放一個專門的接口去對應(yīng)接收

66、數(shù)據(jù)，因此這個接口的設(shè)計是單一的。同時也是最穩(wěn)定的設(shè)計。攝像頭和CMS的連接這之間是有一個錄像管理服務(wù)器的，所以在設(shè)計的時候需要考慮到在這幾個模塊之間的銜接，如圖3-15是關(guān)于錄像服務(wù)的接口設(shè)計。</p><p>　　圖3-15 攝像接口設(shè)計</p><p>　　由于需要考慮到實時視頻數(shù)據(jù)和錄像服務(wù)是需要同步進行的，因此在設(shè)計的時候需要考慮到數(shù)據(jù)的同步性，在處理推送同步視頻數(shù)據(jù)的同時也需要

67、發(fā)送錄像的命，因此設(shè)計的時候需要將這個接口同步設(shè)置，讓CMS可以同時去處理這些命令。</p><p>　　4 流媒體消息服務(wù)器實現(xiàn)</p><p>　　4.1 流媒體交互中的消息傳遞設(shè)計</p><p>　　對于在消息交互過程中的交互方式協(xié)議的原則，協(xié)議的包含部分，消息的頭部包含的信息以及消息主題部分攜帶的主體內(nèi)容有一個明確的規(guī)定，以及定義詳細的消息類型。</

68、p><p>　　交互協(xié)議設(shè)計原則,客戶端與服務(wù)器通訊過程中，信息以消息為載體進行傳輸，每條消息都包含有消息頭和消息的數(shù)據(jù)部分構(gòu)成：消息頭部以HTTP協(xié)議構(gòu)成，以\r\n\r\n結(jié)尾；數(shù)據(jù)部分采用Json文本協(xié)議，保證協(xié)議高可讀性和擴展性。</p><p>　　消息類型定義對于數(shù)據(jù)的信息的交互，如果單純的傳遞消息去解析會有很多的麻煩。所以對解析的信息做了一個統(tǒng)一的定義，每一個請求消息的類型事先聲

69、明好，在解析的時候根據(jù)事先定義好的數(shù)據(jù)類型去做相應(yīng)的解析工作，這樣對整個消息傳遞過程就有了一個很明確的流程。所以做了一下的信息類型定義。表4-1顯示的定義的消息類型。</p><p>　　表4-1 消息傳遞類型</p><p>　　4.2 客戶端登錄到服務(wù)器的實現(xiàn)過程</p><p>　　客戶端登錄到服務(wù)器的這一個過程發(fā)送一個HTTP請求，請求中攜帶這Restful

70、模式的JSON類型數(shù)據(jù)。JSON中封裝了客戶端的相關(guān)信息。CMS服務(wù)器接收到了這請求后，將數(shù)據(jù)存儲到Redis數(shù)據(jù)庫中作為一個Session存儲。用以整個交互過程中的唯一識別標志來存儲。在其他交互過程中用到的請求都是通過這次存儲的數(shù)據(jù)作為一個索引表示來確定客戶端的唯一性。這個信息的交互過程可以通過如圖4-2的流程圖中看出整體的過程。</p><p>　　圖4-2 數(shù)據(jù)存儲消息指令的過程</p>&l

71、t;p>　　從圖4-2中可以看出，當客戶端登錄進服務(wù)器系統(tǒng)后，所傳遞的主要信息是客戶端的IP地址和Port端口號，CMS獲取到這些信息后會和數(shù)據(jù)庫服務(wù)器做一個信息交互，將這客戶端的信息存儲到Redis數(shù)據(jù)庫中，做一個持久的存儲，以方便后續(xù)的數(shù)據(jù)交互。這個交互過程在系統(tǒng)中不是唯一的，當客戶端由于網(wǎng)絡(luò)原因掉線重新登錄后。CMS首先會到數(shù)據(jù)庫中去檢索是否已經(jīng)存在了該條記錄，如過存在更新記錄的時間，刪除數(shù)據(jù)庫中舊的Session信息然后將

72、現(xiàn)在登錄的信息更新。這樣子可以保證客戶端在系統(tǒng)中的信息的穩(wěn)定性，對后續(xù)的更能請求有一個好的信息維護。對于這個過程，在系統(tǒng)中的代碼實現(xiàn)過程如圖4-3所示。</p><p>　　圖4-3 數(shù)據(jù)存儲消息指令的代碼過程</p><p>　　客戶端登錄進系統(tǒng)在CMS服務(wù)器中，首先是總的函數(shù)模塊來加載整個注冊方法，這個函數(shù)模塊中包含數(shù)據(jù)庫的連接和存儲相關(guān)的方法沒客戶端接入后，會將相應(yīng)的參數(shù)信息傳遞給注

73、冊方法，然后將數(shù)據(jù)存儲到數(shù)據(jù)庫中這樣就完成了登錄過程。</p><p>　　4.3 客戶端請求在線流媒體信息的實現(xiàn)過程</p><p>　　請求RESTful,http://[ip]:[port]/api/getdevicelist其中IP是服務(wù)器的IP地址，是根據(jù)請求的IP地址和本機的端口號來請求服務(wù)器響應(yīng)數(shù)據(jù)的。響應(yīng)：MSG_SC_DEVICE_LIST_ACK，相應(yīng)頭部攜帶著消息的請

74、求類型，狀態(tài)碼和消息執(zhí)行的信息。消息的主體部分攜帶著本次請求的客戶端類型，序列編號，處理該消息的流媒體服務(wù)器信息，以及消息的處理碼。從這些交互的信息就可以分析出整個的請求過程，客戶端向CMS發(fā)起一個請求，請求的數(shù)據(jù)中攜帶著獲取在線信息列表這個請求。消息管理服務(wù)器解析了這個請求，然后將處理后的消息返回過去，這樣子一個交互過程就實現(xiàn)了，這個實現(xiàn)過程中的信息交互過程如圖4-4所示。</p><p>　　圖4-4 傳遞在

75、線流媒體信息的指令過程</p><p>　　傳遞的接口中的信息類型都是事先已經(jīng)定義好的數(shù)據(jù)類型通過這樣的傳遞方式，講數(shù)據(jù)指令在服務(wù)器端和客戶端之間來進行信息通信。其中MSG_SC_DEVICE_LIST_ACK正是已經(jīng)定義好了的請求在線視頻信息列表的請求，在系統(tǒng)中的代碼實現(xiàn)過程如圖4-5所示。</p><p>　　圖4-5 傳遞在線流媒體信息的代碼過程</p><p&g

76、t;　　客戶端發(fā)送獲取在線視頻數(shù)據(jù)的請求，在實現(xiàn)的過程中首先是通過主函數(shù)模塊來初始化所以的函數(shù)，對于客戶端的請求，通過調(diào)用請求處理的方法來響應(yīng)在線視頻信息。</p><p>　　4.4 客戶端請求通道攝像機實時碼流推送</p><p>　　請求MSG_SD_PUSH_STREAM_REQ，請求的消息中包含著以下的信息，Serial設(shè)備序列號。Channe攝像機通道號。Protocol指定流

77、媒體傳輸協(xié)議，如：RTSP、自定義協(xié)議等等。Server_IP推送碼流到的流媒體服務(wù)器地址。Server_Port推送碼流到的流媒體服務(wù)器端口。CMS為控制拉流和推流的合法性生成唯一的 StreamID并存儲在 Redis上由Darwin進行判斷是否合法。From：CMS接收Client訪問的SessionID，To：CMS向 Device發(fā)送報文的SessionID，Via：CMS 的ServiceID，請求的消息傳遞指令過程可以通過

78、圖4-6來分析這個過程。</p><p>　　圖4-6 請求在線流媒體推送的指令過程</p><p>　　響應(yīng)：MSG_DS_PUSH_STREAM_ACK頭部攜帶版本信息類型顯示信息等類型的數(shù)據(jù)。消息主體部分攜帶序列編碼，返回消息的個數(shù)，消息來源。消息接收點。其中還包含Server_IP和Server_Port 在此返回的是設(shè)備實際推流的IP和端口。以上就是在客戶請求實時的監(jiān)控視頻的請求

79、過程，消息管理服務(wù)器會向?qū)?yīng)的服務(wù)發(fā)送相應(yīng)的請求，然后解析返回過來的請求數(shù)據(jù)。</p><p>　　圖4-7 請求在線流媒體推送的返回指令過程</p><p>　　請求部分的指令是需要到錄像服務(wù)器部分和攝像頭部分的，但是作為消息回饋的部分，在指令交互這一塊只有CMS和Client之間的交互，通過這兩個交互流程來完成了在實時攝像頭流媒體數(shù)據(jù)的推送，代碼實現(xiàn)請求過程如圖4-8所示。</p

80、><p>　　圖4-8 請求在線流媒體推送的返回代碼過程</p><p>　　客戶端請求攝像機實時視頻，首先還是通過主函數(shù)模塊來加載所有的函數(shù)模塊，然后獲取在線視頻信息列表，對于客戶端的實時攝像頭視頻數(shù)據(jù)通過當前流媒體視頻數(shù)據(jù)的方法來處理這個請求。</p><p>　　4.5 客戶端退出系統(tǒng)的實現(xiàn)</p><p>　　當客戶端退出系統(tǒng)的時候會發(fā)送

81、退出登錄的實時請求，或者當客戶端沒有網(wǎng)絡(luò)訪問的時候也會有對應(yīng)的失去連接請求，這種時候CMS會連接接口來判斷和客戶端之間的連接是否還在，如過連接失去了那么系統(tǒng)將自動關(guān)閉這條來連接，刪除本次連接的會話數(shù)據(jù)。</p><p>　　圖4-9 客戶端退出系統(tǒng)的指令過程</p><p>　　當客戶端退出系統(tǒng)后，CMS服務(wù)器會通過Redis服務(wù)器去數(shù)據(jù)庫中查找退出的客戶端的相關(guān)數(shù)據(jù)，然后將對應(yīng)的數(shù)據(jù)記錄

82、刪除。這樣子本次退出連接的過程就完成了，下次客戶端登錄過來生成新的記錄，這個在代碼中的實現(xiàn)調(diào)用過程如4-10圖所示。</p><p>　　圖4-10 客戶端退出系統(tǒng)代碼過程</p><p>　　4.6服務(wù)器系統(tǒng)登出的實現(xiàn)</p><p>　　當流媒體服務(wù)器系統(tǒng)的某一部分服務(wù)器出現(xiàn)問題的時候為了不影響整體系統(tǒng)的運行，需要為單個模塊設(shè)計登出服務(wù)，這樣子設(shè)計可以避免當某一

83、模塊的系統(tǒng)出項問題的時候影響到整個系統(tǒng)的運行。在這個部分的設(shè)計上系統(tǒng)要設(shè)置雙向的登出操作，從CMS上退出其他系統(tǒng)的數(shù)據(jù)，以及在退出系統(tǒng)上退出當前的CMS數(shù)據(jù)。</p><p>　　圖4-11 服務(wù)器系統(tǒng)登出的過程</p><p>　　各系統(tǒng)模塊登出的過程和客戶端登出的指令流程類似，但是執(zhí)行的系統(tǒng)指令完全不一樣，客戶端是通過Http請求來確定是否在線，而服務(wù)器端是通過RSTP協(xié)議來實現(xiàn)信息交

84、互，因此指令數(shù)據(jù)的傳遞是實時的，退出系統(tǒng)也是雙向的，這個在代碼中的實現(xiàn)調(diào)用過程如圖4-12所示。</p><p>　　圖4-12 服務(wù)器系統(tǒng)登出的代碼過程</p><p>　　服務(wù)器登出的過程是系統(tǒng)的生命周期中的一部分，在各服務(wù)器模塊登錄進CMS的時候會初始化各模塊內(nèi)容，初始化后會在CMS中存在session記錄。當服務(wù)器模塊退出后session會過期，會自動回收這部分的數(shù)據(jù)。</p

85、><p><b>　　5 系統(tǒng)測試</b></p><p><b>　　5.1 測試的方法</b></p><p>　　本次測試采用的是黑盒測試的方法，通過運行服務(wù)器，觀察服務(wù)器在運行的過程中的數(shù)據(jù)輸出情況來判斷系統(tǒng)是否能夠正常的運行，以及系統(tǒng)運行的結(jié)果是否服務(wù)系統(tǒng)的設(shè)計標準，測試本系統(tǒng)的過程中是依賴于整個的流媒體服務(wù)器來的。

86、測試過程包括開啟服務(wù)后對應(yīng)的服務(wù)器是否注冊到流媒體消息服務(wù)器中，在做數(shù)據(jù)請求的時候控制臺打印的消息是否符合運行的標準。</p><p><b>　　5.2 測試過程</b></p><p>　　在本機中測試該項目，將整套系統(tǒng)相關(guān)的項目都編譯成可執(zhí)行的文件后。啟動對應(yīng)的服務(wù)然后連接電腦。開啟數(shù)據(jù)庫連接服務(wù)，測試數(shù)據(jù)庫是否能正常啟動。</p><p&g

87、t;　　表5-1 開啟數(shù)據(jù)庫服務(wù)</p><p>　　如圖5-2顯示的數(shù)據(jù)庫服務(wù)器啟動后的效果，數(shù)據(jù)庫相關(guān)的服務(wù)開啟等待著其他服務(wù)器的連接，在開啟其他流媒體服務(wù)器后在此服務(wù)器上會有對應(yīng)的數(shù)據(jù)流信息。</p><p>　　圖5-2 數(shù)據(jù)庫服務(wù)</p><p>　　測試數(shù)據(jù)庫服務(wù)開啟正常后，數(shù)據(jù)庫服務(wù)器開始等待其他服務(wù)器的連接，這個時候開始去測試Camera服務(wù)器是否能

88、夠正常的啟動成功。</p><p>　　表5-3 開啟數(shù)據(jù)庫服務(wù)</p><p>　　Camera相關(guān)的服務(wù)器啟動后，Camera心跳?；畹臄?shù)據(jù)如圖5-2顯示的數(shù)據(jù)，Camera服務(wù)器一直在顯示外界的視頻流媒體相關(guān)的消息。</p><p>　　圖5-4 Camera心跳保活顯示</p><p>　　數(shù)據(jù)庫服務(wù)器和Camera服務(wù)器都正常啟動后

89、，準備測試CMS服務(wù)器，開啟CMS服務(wù)器去觀察服務(wù)器窗口的打印信息，看是否正常的連接到已開啟的數(shù)據(jù)庫服務(wù)器和Camera服務(wù)器</p><p>　　表5-5 開啟數(shù)據(jù)庫服務(wù)</p><p>　　中心消息流媒體服務(wù)器的顯示數(shù)據(jù)如圖5-6顯示，在該控制臺上顯示的數(shù)據(jù)正是本次測試的內(nèi)容，分析圖中的數(shù)據(jù)可以看出在整個系統(tǒng)的運行過程中，相關(guān)的服務(wù)器都和消息流媒體服務(wù)器有一個信息的交互。</p&

90、gt;<p>　　圖5-6 消息服務(wù)器</p><p>　　依次將數(shù)據(jù)庫服務(wù)、Darwin服務(wù)、CMSS服務(wù)、錄像服務(wù)、攝像服務(wù)開啟后啟動了整個系統(tǒng)的所有服務(wù)。然后打開手機的客戶端，通過將客戶端上的登錄地址設(shè)定成服務(wù)器上同樣的地址端口號設(shè)置成CMSS配置的端口，開始連接服務(wù)器。整個的請求過程中的消息交互都是在CMS中進行的，從系統(tǒng)進入就開始注冊系統(tǒng)的消息，每一個請求都是通過CMS來做相應(yīng)的處理，從數(shù)

91、據(jù)流顯示的數(shù)據(jù)來看，系統(tǒng)登錄到CMS保持系統(tǒng)間的會話，系統(tǒng)中處理相應(yīng)的請求都有對應(yīng)的數(shù)據(jù)信息打印出來。</p><p>　　圖5-7 消息服務(wù)器</p><p><b>　　5.3 測試總結(jié)</b></p><p>　　通過測試過程中的數(shù)據(jù)分析本次測試過程從客戶端到服務(wù)器，從服務(wù)器到客戶端這幾個交互過程都是如此的執(zhí)行的。客戶端像服務(wù)器端請求攝像

92、頭數(shù)據(jù)，消息管理器處理該請求，像攝像頭相關(guān)的服務(wù)發(fā)送了請求指令，攝像頭服務(wù)將流媒體數(shù)據(jù)推送給Darwin,Darwin將流媒體數(shù)據(jù)推送到客戶端上，客戶端解析了該流媒體數(shù)據(jù)后顯示出了視頻數(shù)據(jù)，這整一個交互過程的信息指令都通過消息服務(wù)器處理，在整個的信息的交互過程中，CMS都是在對相應(yīng)的數(shù)據(jù)進行著處理，每一個請求的數(shù)據(jù)也都是打印在控制臺中。顯示的數(shù)據(jù)也都是和系統(tǒng)設(shè)計之初定義的數(shù)據(jù)是一致的，</p><p>　　對整個

93、測試過程中的數(shù)據(jù)分析最后可以得出的結(jié)論是，本系統(tǒng)的設(shè)計是符合Apple Darwin的流媒體的設(shè)計標準的。</p><p><b>　　參考文獻</b></p><p>　　楊海瀾．流媒體系統(tǒng)中的幾項關(guān)鍵技術(shù)分析及應(yīng)用[J]．武漢交通職業(yè)學(xué)院學(xué)報，2014：132-150</p><p>　　董科軍，南凱，閻保平．一種可擴展的集群流媒體服務(wù)器[

94、J]．計算機工程與應(yīng)用，2015：15-25</p><p>　　丁杰，潘晨光，田源．基于crtmpserver的手機直播系統(tǒng)[J]．計算機工程與設(shè)計，2014：32-10</p><p>　　姜浩然，徐林．基于RTMP的流媒體服務(wù)器的研究[J]．計算機與數(shù)字工程，2015：132-150</p><p>　　史紅周，黃晁．一種基于MP4文件的視頻流關(guān)鍵幀索引播放方

95、法[J]．微電子學(xué)與計算機，2015</p><p>　　李新樂，蘇鴻根．流媒體搜索和發(fā)布技術(shù)在移動設(shè)備上的應(yīng)用[J]．計算機工程與設(shè)計，2014</p><p>　　茅炎菲，黃忠東．基于RTSP協(xié)議網(wǎng)絡(luò)監(jiān)控系統(tǒng)的研究與實現(xiàn)[J]．計算機工程與設(shè)計，2015</p><p>　　羅大暉，陳娟．基于HTML5的Web離線應(yīng)用研究與實現(xiàn)[J]．計算機應(yīng)用與軟件，2015

96、：2-8</p><p>　　李校林，劉海波，張杰．RTP/RTCP，RTSP在無線視頻監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)[J]．電視技術(shù)，2015：89-92</p><p>　　韋崇嶺，裴海龍．基于無人機平臺H264視頻傳輸系統(tǒng)的設(shè)計與實現(xiàn)[J]．計算機測量與控制，2015，20（1）：209-211</p><p>　　劉麗霞，邊金松，張琍，等．基于FFMPEG解碼的音視頻

97、同步實現(xiàn)[J]．計算機工程與設(shè)計，2016，34（6）：2087-2092</p><p>　　李興華，楊天奇．MP4共享FLV數(shù)據(jù)研究與實現(xiàn)[J]．微型機與應(yīng)用，2014：31-34</p><p>　　楊金花，宋寶瑜．移動流媒體在遠程教育中的關(guān)鍵性技術(shù)及應(yīng)用研究[J]．遠程教育雜志，2015，20（2）：109-1</p><p>　　羅瑋華，楊堅，鄭烇，胡晗．

98、一種支持視頻VCR操作的共享動態(tài)緩存算法[J]．計算機應(yīng)用，2016，203（2）：09-1</p><p>　　路衛(wèi)娜，楊壽保，郭磊濤．P2P流媒體系統(tǒng)中積分檢測相結(jié)合的激勵機制[J]．中國科學(xué)院研究生院學(xué)報，2015（1）：209-211</p><p>　　胡文彥，葉德建．基于應(yīng)用層組播的高清流媒體直播原型系統(tǒng)的實現(xiàn)和測試[J]．中國圖象圖形學(xué)報，2014（10）20-11</

99、p><p>　　Optimizing patching performance. Y Cai,et al.IEEE Inter-national Conference on Multimedia Computing and Networking [J]. 2016:23-211</p><p>　　Optimized batch patching with classesof service.

100、 P P White,J Crowcroft. ACM of the Communications [J]. 2015:23-11</p><p>　　JimArlowIIaNeustadt. UML2andtheUnifiedProcess.PracticalObject-OrientedAnalysisandDesign[J] . SecondEdition. 2016:123-12</p>&

101、lt;p>　　On peer-to-peer mediastreaming. Xu D,Hefeeda M,Hambrusch S,et al[J]. IEEE Conference on Distributed ComputingSystems. 2015:2-21</p><p>　　Spivak,G."CantheSubalternSpeak?". InC.Nelson&L

102、.Grossberg(eds.). VictoryinLimbo:Imigism[C].Urbana:UniversityofIllinoisPress. 2015,pp.271-313</p><p>　　Incentives for sharingin peer-to-peer networks. Golle P,Leylton-Brown K,Mironov I. proc.Of second worksh

103、op onelectronic commerce(WELCOM’01) [J] . 2015:32-21</p><p>　　Crackton,P. TheLoonie:God'slong-awaitedgifttocolourfulpocketchange[J]. CanadianChange. 64(7)2016.34–37</p><p>　　Data striping an

104、d reliability aspects in distributed video servers[J]. Jamel Gafsi,Ernst W. Biersack. . Cluster Computing. 2016(1)</p><p>　　Multime-dia object placement for hybrid transparent data replication[J]. Keqiu Li,H

105、ong Shen,Chin F Y L,Liusheng Huang. IEEE Globecom. 2016</p><p><b>　　致 謝</b></p><p>　　四年的學(xué)習(xí)生活即將結(jié)束，即將步入社會，回顧大學(xué)生活感觸頗深。這個畢業(yè)設(shè)計是在張志強導(dǎo)師指導(dǎo)下完成的，在選題完畢之后，編碼和寫論文的過程中有很多困難，在張老師的教導(dǎo)和幫助下，最終成功的完成了系統(tǒng)和

106、論文。通過完成畢業(yè)設(shè)計使本人在文獻查閱，實踐技術(shù)以及撰寫論文方面均有了很大的提高。借此，向張老師表示深深的感謝，他像知心朋友一樣給予鼓勵，在系統(tǒng)的設(shè)計和論文的寫作方面嚴格要求，這才使本人可以完成這次畢業(yè)設(shè)計。除此還要感謝同學(xué)們，是他們在困難的時候給予幫助，并給了很多很好的建議。對于這個系統(tǒng)的整個設(shè)計過程一開始拿到這個題的時候還是很茫然的不知道如何去下手，再網(wǎng)上查閱了相關(guān)的資料和自己學(xué)習(xí)了相關(guān)的網(wǎng)絡(luò)傳輸協(xié)議之后開始有了一個簡單的認知，但是