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

丁玲　王孟陽

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

關鍵詞： 錄播； 數據傳輸； 沖突識別； 備保切換

中圖分類號： 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 引 言

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

1 錄播系統系統構成介紹

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

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

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

2 展示室錄播系統沖突分析

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

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

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

3 備保傳輸系統設計

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

3.1 備保系統的設計

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

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

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

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

3.2 沖突識別算法的設計

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

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

為保證視頻流暢性，主要關注識別到沖突后備保切換的時間對數據傳輸的影響以及對視頻質量的影響。表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級，且視頻播放穩定在512 Kb/s，表明系統工作穩定可以支持錄播系統工作。

表1 備保切換品質參數表

5 結 論

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

參考文獻

[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的數據挖掘技術在網站優化中的個性化推薦方法的研究與應用[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] 夏惠芬，董衛民. 基于關聯規則的Web挖掘技術研究[J].現代電子技術，2011，34（16）：100?102.

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

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

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

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

3.2 沖突識別算法的設計

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

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

為保證視頻流暢性，主要關注識別到沖突后備保切換的時間對數據傳輸的影響以及對視頻質量的影響。表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級，且視頻播放穩定在512 Kb/s，表明系統工作穩定可以支持錄播系統工作。

表1 備保切換品質參數表

5 結 論

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

參考文獻

[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的數據挖掘技術在網站優化中的個性化推薦方法的研究與應用[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] 夏惠芬，董衛民. 基于關聯規則的Web挖掘技術研究[J].現代電子技術，2011，34（16）：100?102.

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

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

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

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

3.2 沖突識別算法的設計

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

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

為保證視頻流暢性，主要關注識別到沖突后備保切換的時間對數據傳輸的影響以及對視頻質量的影響。表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級，且視頻播放穩定在512 Kb/s，表明系統工作穩定可以支持錄播系統工作。

表1 備保切換品質參數表

5 結 論

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

參考文獻

[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的數據挖掘技術在網站優化中的個性化推薦方法的研究與應用[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] 夏惠芬，董衛民. 基于關聯規則的Web挖掘技術研究[J].現代電子技術，2011，34（16）：100?102.