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

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

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

3、　分類號(hào) 密級(jí)</p><p>　　華中農(nóng)業(yè)大學(xué)楚天學(xué)院本科畢業(yè)論文</p><p>　　基于Apple Darwin的流媒體消息管理服務(wù)器的設(shè)計(jì)與實(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 課題目標(biāo)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è)計(jì)4</p><p>　　3.1 流媒體消息服務(wù)器的系統(tǒng)框架4</p><p>　　3.2 客戶端請(qǐng)求到服務(wù)器的過(guò)程5</p><p>　　3.3 客戶端請(qǐng)求在線流媒體信息的過(guò)程7</p><p>　　

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

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

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

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

12、功能部分的交互部分。開(kāi)發(fā)基于Darwin的流媒體服務(wù)器使用VS2008作為開(kāi)發(fā)工具，整個(gè)服務(wù)器的開(kāi)發(fā)過(guò)程主要的解決方案是處理各服務(wù)器部分的信息交互部分，對(duì)于客戶端使用HTTP協(xié)議來(lái)進(jìn)行信息交互，服務(wù)器之間使用RSTP協(xié)議來(lái)進(jìn)行信息交互。</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ú)線網(wǎng)絡(luò)的飛速發(fā)展和技術(shù)的不斷更新，互聯(lián)網(wǎng)已經(jīng)普及到每一個(gè)普通的家庭。Internet的基礎(chǔ)架構(gòu)慢慢趨于完善，對(duì)于網(wǎng)絡(luò)上信息的交互

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

98、一種支持視頻VCR操作的共享動(dòng)態(tài)緩存算法[J]．計(jì)算機(jī)應(yīng)用，2016，203（2）：09-1</p><p>　　路衛(wèi)娜，楊壽保，郭磊濤．P2P流媒體系統(tǒng)中積分檢測(cè)相結(jié)合的激勵(lì)機(jī)制[J]．中國(guó)科學(xué)院研究生院學(xué)報(bào)，2015（1）：209-211</p><p>　　胡文彥，葉德建．基于應(yīng)用層組播的高清流媒體直播原型系統(tǒng)的實(shí)現(xiàn)和測(cè)試[J]．中國(guó)圖象圖形學(xué)報(bào)，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é)束，即將步入社會(huì)，回顧大學(xué)生活感觸頗深。這個(gè)畢業(yè)設(shè)計(jì)是在張志強(qiáng)導(dǎo)師指導(dǎo)下完成的，在選題完畢之后，編碼和寫(xiě)論文的過(guò)程中有很多困難，在張老師的教導(dǎo)和幫助下，最終成功的完成了系統(tǒng)和

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