專利名稱：：共享內存流媒體服務器的運行方法及其功能模塊構架的制作方法
技術領域：
：本發明屬于一種流媒體服務器，特別是一種內核進程和用戶進程采用共享內存的流媒體服務器的運行方法及該服務器為實現其運行方法的功能模塊構架。
背景技術：
：近年來，隨著高速網絡、高帶寬存儲設備以及媒體編碼壓縮技術的迅速發展，使得通過網絡提供實時流媒體服務成為可能。流媒體技術廣泛用于多媒體新聞發布、在線直播、網絡廣告、電子商務、視頻點播、遠程教育、遠程醫療、網絡電視臺和實時視頻會議等互聯網信息服務的方方面面。流媒體應用的關鍵問題是流媒體服務器的性能，多數在數字媒體領域著名的公司都開發推出了包括服務器和播放器在內的一整套流媒體解決方案。目前，流媒體服務器優化的熱點主要有將點對點技術與流媒體整合，克服了傳統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日發明者毅李,楊曉冬,鵬王,旭董,宇辜申請人:電子科技大學