基于沖突識別的遠程教育錄播系統(tǒng)備保切換的設計與仿真

丁玲　王孟陽

摘 要： 為了應對遠程教育中微格錄播系統(tǒng)數(shù)據(jù)傳輸過程中產生沖突導致數(shù)據(jù)中斷的問題，保證系統(tǒng)工作的流暢進行，設計了沖突監(jiān)測方案和備保切換模塊，可實現(xiàn)實時監(jiān)測系統(tǒng)，在產生沖突后快速切換至備保服務器繼續(xù)傳輸數(shù)據(jù)。通過仿真證實系統(tǒng)可快速切換備保服務器，且切換時間與主機程序重啟時間較短，可在保證用戶錄播視頻質量的同時使微格錄播系統(tǒng)滿足數(shù)據(jù)傳輸要求。

關鍵詞： 錄播； 數(shù)據(jù)傳輸； 沖突識別； 備保切換

中圖分類號： TN919?34； TP23 文獻標識碼： A 文章編號： 1004?373X（2014）10?0073?04

Abstract： In order to solve the problem of data interruption caused by conflict produced during data transfer of microformat record/play?back system in remote education to ensure smooth working of the system， the conflict monitoring scheme and protection switching module was designed to achieve the real?time monitoring system， which can quickly switch to the backup server to continue the data transmission when conflict occurs. The simulation result confirms that the system can quickly switch to the backup security server， and the switching time is short same as the host program restart time. It can ensure the users′ video record/play?back quality while the microformat record/play?back system meets the data transmission requirements.

Keywords： record and play back； data transmission； conflict recognition； protection switching

0 引 言

時代發(fā)展日新月異，各行各業(yè)對于多媒體的依靠也越來越多，其中錄播系統(tǒng)作為一種新型的展示平臺，因其具有快速傳遞信息的能力而被廣泛接受。錄播系統(tǒng)指以具有特定需求的人為對象，將制錄像修改、濃縮成短時間內的展示內容，以課堂形式展現(xiàn)給觀眾。錄播系統(tǒng)對配套軟硬件設備要求較高。通過硬件如攝像錄音設備，以及軟件如視頻處理和音頻處理軟件將授課錄制成的數(shù)字視頻通常較大，而錄播的展示平臺要求具有連續(xù)性和時效性，要保證每個用戶均可享受服務，就務必保證數(shù)字信號傳輸?shù)姆€(wěn)定性以及足夠帶寬。但往往硬件條件滿足時，亦會出現(xiàn)多用戶分段傳輸過程中，沖突情況的出現(xiàn)，造成網(wǎng)絡傳輸沖突。為網(wǎng)絡傳輸沖突，必須針對特定的硬件條件配合具體算法來對系統(tǒng)進行優(yōu)化。

1 錄播系統(tǒng)系統(tǒng)構成介紹

錄播系統(tǒng)由大量軟件及硬件構成，根據(jù)不同的需求也有不同的定制方案，但就完整的錄播系統(tǒng)應該具有輸入輸出，過程監(jiān)控，品質保障以及備份等功能。就硬件來說錄播系統(tǒng)包括控制間以及展示室兩部分。

控制間里布置了大量設備，這些設備包括服務器、主控計算機、高清攝像頭、錄像機、監(jiān)控臺、監(jiān)視器以及功放設備等[1]。主控室對展示室設備工作進行監(jiān)視和控制。通過安裝在展示室的攝像裝置，采集環(huán)境情況。并實現(xiàn)播放。

展示室包括主要包括監(jiān)控攝像頭，視頻音頻設備，用戶分控器等。展示室內計算機可上傳請求給主控室，亦可呼叫主控室，并與主控室進行溝通。展示室也可以自行控制位于本區(qū)域的監(jiān)控設備，音頻視頻設備，收集錄制展示室的聲音和圖像，作為后續(xù)的分析和評估資料。 分控機可以選擇數(shù)據(jù)庫課程資源，并控制顯示設備，音頻設備的播放、暫停、停止、速度調節(jié)等功能[2]。

2 展示室錄播系統(tǒng)沖突分析

因為展示室錄播具有遠程控制，傳輸數(shù)據(jù)量大以及節(jié)點多等特點，使得其系統(tǒng)較為復雜，為保證多個任務同時工作，需采用同步和多線程技術[3]。但多線程工作容易產生阻塞形成沖突，影響系統(tǒng)工作效率。

沖突是數(shù)據(jù)傳輸過程中數(shù)個等待進程下載服務器共享資源產生沖突而形成的互相等待現(xiàn)象，這種等待使得進程請求阻塞，需借助其他程序或認為控制解除。由于服務器CPU工作的分時性，所以節(jié)點請求資源傳輸是互斥操作，為了提高系統(tǒng)性能和數(shù)據(jù)傳輸吞吐量需引入防沖突機制[4]，鎖也對系統(tǒng)高效和安全運行具有明顯作用，但產生沖突后，節(jié)點請求無法滿足會產生停滯反而會影響系統(tǒng)工作。數(shù)據(jù)傳輸沖突原理圖如圖1所示。

通信沖突是一種程序錯誤，是大系統(tǒng)工作很難避免的現(xiàn)象。沖突的種類非藏多，操作系統(tǒng)內核源碼有上千萬行，沖突具有大量產生點，在現(xiàn)有技術條件下，不可能避免沖突的產生[5]。所以在數(shù)據(jù)傳輸中應采用有效方式，應對沖突。

3 備保傳輸系統(tǒng)設計

為了避免傳輸過程中沖突影響播放流暢性，在此設計了沖突的識別模塊，提出一種快速地沖突識別機制。當識別到沖突后，系統(tǒng)即使報告檢測信息。由于解沖突過程較為困難，會導致系統(tǒng)無法傳輸信息，此處構建備保服務器進行數(shù)據(jù)傳輸，克服了沖突以及解沖困難。下面分工作流程以及沖突識別模塊兩方面介紹分析系統(tǒng)。

3.1 備保系統(tǒng)的設計

首先，控制系統(tǒng)會將目標視頻分成若干數(shù)據(jù)包，數(shù)據(jù)包大小依據(jù)服務器與用戶網(wǎng)絡傳輸速度而定，網(wǎng)速越，數(shù)據(jù)包可設置越大。另外也要考慮用戶數(shù)量，數(shù)量較多時需設置較小的數(shù)據(jù)包，避免單個用戶傳輸時間過長，以保證用戶下載的同步性。

數(shù)據(jù)包的分割要遵循視頻文件的時序，不可措置時間，而且要掌握視頻信息與音頻信息時間對應，數(shù)據(jù)包同時也被嚴格按時間先后編號。

備保傳輸流程如圖2所示，在控制端設置與主機功能相近的服務器作為主機的備保，在主機工作過程中，引入沖突識別模塊，對數(shù)據(jù)包傳輸中沖突進行識別。如若傳輸正常，則多線程繼續(xù)用戶傳輸，如若發(fā)現(xiàn)沖突，則啟動備保，并重啟主機程序，從而消沖突，重啟程序后的主機為備保，交替工作。

此時備保機為達到視頻信號傳輸同步需查找用戶接收數(shù)據(jù)包時序信息，傳輸下一時刻數(shù)據(jù)包。其工作原理同主機工作相同。在傳輸過程依然引入沖突識別模塊，一旦發(fā)現(xiàn)沖突立即切換至已經重啟的主機繼續(xù)傳輸。

3.2 沖突識別算法的設計

互斥進程同時請求服務器服務時，在同一時刻只能有一個線程訪問該對象。如果一個進程已經將資源鎖定，就會使傳輸序列沖突，導致了另外的用戶服務請求進程不停地循環(huán)，無法獲取服務，進而產生沖突。

如圖3所示，主機傳輸停止并重啟傳輸程序后產生短暫數(shù)據(jù)傳輸中斷，備保機正常工作后數(shù)據(jù)傳輸恢復正常，由于2個服務器配置相同帶寬不變，視頻傳輸質量未受影響。證明系統(tǒng)可正常進行傳輸切換并保證數(shù)據(jù)傳輸。

為保證視頻流暢性，主要關注識別到沖突后備保切換的時間對數(shù)據(jù)傳輸?shù)挠绊懸约皩σ曨l質量的影響。表1為6次備保切換的用時，沖突機的傳輸程序重啟時間，和切換時間用戶最小視頻質量。

切換耗時平均值為38.3 ms，最快37.9 ms，最慢40.2 ms；重啟耗時平均值為68.1 ms，最快時間為60.5 ms，最慢時間80.7 ms；切換備保機期間最小播放質量為1 024 Kb/s。備保切換與服務器傳輸程序重啟時間均為ms級，且視頻播放穩(wěn)定在512 Kb/s，表明系統(tǒng)工作穩(wěn)定可以支持錄播系統(tǒng)工作。

表1 備保切換品質參數(shù)表

5 結 論

錄播系統(tǒng)對數(shù)據(jù)傳輸穩(wěn)定性要求較高，但易產生沖突導致系統(tǒng)卡滯。本文針對這個問題，分析了錄播系統(tǒng)的構成，并設計與之配套的沖突識別方案，同時設計了備保傳輸系統(tǒng)，可在產生沖突后切換至備保服務器傳輸數(shù)據(jù)。最后通過仿真證實系統(tǒng)工作正常，并在短時間內完成備保切換和主機程序重啟，可滿足錄播系統(tǒng)的要求。

參考文獻

[1] 李晉，葛敬國.Linux下互斥機制及其分析[J].計算機應用研究，2005（8）：72?77.

[2] 彭正文，徐新愛.基于SMP的Linux內核自旋鎖分析[J].江西師范學院學報：綜合版，2005（3）：23?28.

[3] COFFMAN E G， ELPHICK M， SHOSHANI A. System deadlocks [J]. ACM Comput Surv， 1971， 3（2）： 67?78.

[4] HAVELUND K， PRESSBURGER T. Model checking Java programs using Java pathfinder [J]. International Journal on Software Tools for Technology Transfer， 2000， 2（4）： 366?381.

[5] 宋淑彩.面向Web的數(shù)據(jù)挖掘技術在網(wǎng)站優(yōu)化中的個性化推薦方法的研究與應用[J].科技通報，2012，28（2）：118?119.

[6] HOVEMEYER D， PUGH W. Finding bugs is easy [J]. ACM SIGPLAN Notice， 2004， 39（12）： 92?106.

[7] 夏惠芬，董衛(wèi)民. 基于關聯(lián)規(guī)則的Web挖掘技術研究[J].現(xiàn)代電子技術，2011，34（16）：100?102.

首先，控制系統(tǒng)會將目標視頻分成若干數(shù)據(jù)包，數(shù)據(jù)包大小依據(jù)服務器與用戶網(wǎng)絡傳輸速度而定，網(wǎng)速越，數(shù)據(jù)包可設置越大。另外也要考慮用戶數(shù)量，數(shù)量較多時需設置較小的數(shù)據(jù)包，避免單個用戶傳輸時間過長，以保證用戶下載的同步性。

數(shù)據(jù)包的分割要遵循視頻文件的時序，不可措置時間，而且要掌握視頻信息與音頻信息時間對應，數(shù)據(jù)包同時也被嚴格按時間先后編號。

備保傳輸流程如圖2所示，在控制端設置與主機功能相近的服務器作為主機的備保，在主機工作過程中，引入沖突識別模塊，對數(shù)據(jù)包傳輸中沖突進行識別。如若傳輸正常，則多線程繼續(xù)用戶傳輸，如若發(fā)現(xiàn)沖突，則啟動備保，并重啟主機程序，從而消沖突，重啟程序后的主機為備保，交替工作。

此時備保機為達到視頻信號傳輸同步需查找用戶接收數(shù)據(jù)包時序信息，傳輸下一時刻數(shù)據(jù)包。其工作原理同主機工作相同。在傳輸過程依然引入沖突識別模塊，一旦發(fā)現(xiàn)沖突立即切換至已經重啟的主機繼續(xù)傳輸。

3.2 沖突識別算法的設計

互斥進程同時請求服務器服務時，在同一時刻只能有一個線程訪問該對象。如果一個進程已經將資源鎖定，就會使傳輸序列沖突，導致了另外的用戶服務請求進程不停地循環(huán)，無法獲取服務，進而產生沖突。

如圖3所示，主機傳輸停止并重啟傳輸程序后產生短暫數(shù)據(jù)傳輸中斷，備保機正常工作后數(shù)據(jù)傳輸恢復正常，由于2個服務器配置相同帶寬不變，視頻傳輸質量未受影響。證明系統(tǒng)可正常進行傳輸切換并保證數(shù)據(jù)傳輸。

為保證視頻流暢性，主要關注識別到沖突后備保切換的時間對數(shù)據(jù)傳輸?shù)挠绊懸约皩σ曨l質量的影響。表1為6次備保切換的用時，沖突機的傳輸程序重啟時間，和切換時間用戶最小視頻質量。

切換耗時平均值為38.3 ms，最快37.9 ms，最慢40.2 ms；重啟耗時平均值為68.1 ms，最快時間為60.5 ms，最慢時間80.7 ms；切換備保機期間最小播放質量為1 024 Kb/s。備保切換與服務器傳輸程序重啟時間均為ms級，且視頻播放穩(wěn)定在512 Kb/s，表明系統(tǒng)工作穩(wěn)定可以支持錄播系統(tǒng)工作。

表1 備保切換品質參數(shù)表

5 結 論

錄播系統(tǒng)對數(shù)據(jù)傳輸穩(wěn)定性要求較高，但易產生沖突導致系統(tǒng)卡滯。本文針對這個問題，分析了錄播系統(tǒng)的構成，并設計與之配套的沖突識別方案，同時設計了備保傳輸系統(tǒng)，可在產生沖突后切換至備保服務器傳輸數(shù)據(jù)。最后通過仿真證實系統(tǒng)工作正常，并在短時間內完成備保切換和主機程序重啟，可滿足錄播系統(tǒng)的要求。

參考文獻

[1] 李晉，葛敬國.Linux下互斥機制及其分析[J].計算機應用研究，2005（8）：72?77.

[2] 彭正文，徐新愛.基于SMP的Linux內核自旋鎖分析[J].江西師范學院學報：綜合版，2005（3）：23?28.

[3] COFFMAN E G， ELPHICK M， SHOSHANI A. System deadlocks [J]. ACM Comput Surv， 1971， 3（2）： 67?78.

[4] HAVELUND K， PRESSBURGER T. Model checking Java programs using Java pathfinder [J]. International Journal on Software Tools for Technology Transfer， 2000， 2（4）： 366?381.

[5] 宋淑彩.面向Web的數(shù)據(jù)挖掘技術在網(wǎng)站優(yōu)化中的個性化推薦方法的研究與應用[J].科技通報，2012，28（2）：118?119.

[6] HOVEMEYER D， PUGH W. Finding bugs is easy [J]. ACM SIGPLAN Notice， 2004， 39（12）： 92?106.

[7] 夏惠芬，董衛(wèi)民. 基于關聯(lián)規(guī)則的Web挖掘技術研究[J].現(xiàn)代電子技術，2011，34（16）：100?102.

首先，控制系統(tǒng)會將目標視頻分成若干數(shù)據(jù)包，數(shù)據(jù)包大小依據(jù)服務器與用戶網(wǎng)絡傳輸速度而定，網(wǎng)速越，數(shù)據(jù)包可設置越大。另外也要考慮用戶數(shù)量，數(shù)量較多時需設置較小的數(shù)據(jù)包，避免單個用戶傳輸時間過長，以保證用戶下載的同步性。

數(shù)據(jù)包的分割要遵循視頻文件的時序，不可措置時間，而且要掌握視頻信息與音頻信息時間對應，數(shù)據(jù)包同時也被嚴格按時間先后編號。

備保傳輸流程如圖2所示，在控制端設置與主機功能相近的服務器作為主機的備保，在主機工作過程中，引入沖突識別模塊，對數(shù)據(jù)包傳輸中沖突進行識別。如若傳輸正常，則多線程繼續(xù)用戶傳輸，如若發(fā)現(xiàn)沖突，則啟動備保，并重啟主機程序，從而消沖突，重啟程序后的主機為備保，交替工作。

此時備保機為達到視頻信號傳輸同步需查找用戶接收數(shù)據(jù)包時序信息，傳輸下一時刻數(shù)據(jù)包。其工作原理同主機工作相同。在傳輸過程依然引入沖突識別模塊，一旦發(fā)現(xiàn)沖突立即切換至已經重啟的主機繼續(xù)傳輸。

3.2 沖突識別算法的設計

互斥進程同時請求服務器服務時，在同一時刻只能有一個線程訪問該對象。如果一個進程已經將資源鎖定，就會使傳輸序列沖突，導致了另外的用戶服務請求進程不停地循環(huán)，無法獲取服務，進而產生沖突。

如圖3所示，主機傳輸停止并重啟傳輸程序后產生短暫數(shù)據(jù)傳輸中斷，備保機正常工作后數(shù)據(jù)傳輸恢復正常，由于2個服務器配置相同帶寬不變，視頻傳輸質量未受影響。證明系統(tǒng)可正常進行傳輸切換并保證數(shù)據(jù)傳輸。

為保證視頻流暢性，主要關注識別到沖突后備保切換的時間對數(shù)據(jù)傳輸?shù)挠绊懸约皩σ曨l質量的影響。表1為6次備保切換的用時，沖突機的傳輸程序重啟時間，和切換時間用戶最小視頻質量。

切換耗時平均值為38.3 ms，最快37.9 ms，最慢40.2 ms；重啟耗時平均值為68.1 ms，最快時間為60.5 ms，最慢時間80.7 ms；切換備保機期間最小播放質量為1 024 Kb/s。備保切換與服務器傳輸程序重啟時間均為ms級，且視頻播放穩(wěn)定在512 Kb/s，表明系統(tǒng)工作穩(wěn)定可以支持錄播系統(tǒng)工作。

表1 備保切換品質參數(shù)表

5 結 論

錄播系統(tǒng)對數(shù)據(jù)傳輸穩(wěn)定性要求較高，但易產生沖突導致系統(tǒng)卡滯。本文針對這個問題，分析了錄播系統(tǒng)的構成，并設計與之配套的沖突識別方案，同時設計了備保傳輸系統(tǒng)，可在產生沖突后切換至備保服務器傳輸數(shù)據(jù)。最后通過仿真證實系統(tǒng)工作正常，并在短時間內完成備保切換和主機程序重啟，可滿足錄播系統(tǒng)的要求。

參考文獻

[1] 李晉，葛敬國.Linux下互斥機制及其分析[J].計算機應用研究，2005（8）：72?77.

[2] 彭正文，徐新愛.基于SMP的Linux內核自旋鎖分析[J].江西師范學院學報：綜合版，2005（3）：23?28.

[3] COFFMAN E G， ELPHICK M， SHOSHANI A. System deadlocks [J]. ACM Comput Surv， 1971， 3（2）： 67?78.

[4] HAVELUND K， PRESSBURGER T. Model checking Java programs using Java pathfinder [J]. International Journal on Software Tools for Technology Transfer， 2000， 2（4）： 366?381.

[5] 宋淑彩.面向Web的數(shù)據(jù)挖掘技術在網(wǎng)站優(yōu)化中的個性化推薦方法的研究與應用[J].科技通報，2012，28（2）：118?119.

[6] HOVEMEYER D， PUGH W. Finding bugs is easy [J]. ACM SIGPLAN Notice， 2004， 39（12）： 92?106.

[7] 夏惠芬，董衛(wèi)民. 基于關聯(lián)規(guī)則的Web挖掘技術研究[J].現(xiàn)代電子技術，2011，34（16）：100?102.