一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法
【專利摘要】本發(fā)明涉及一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法，特別適用于多媒體彩鈴大規(guī)模并發(fā)網(wǎng)絡(luò)播放。將播放系統(tǒng)按不同的復(fù)雜度設(shè)置成消息接收模塊、消息處理模塊，發(fā)送模塊和刪除播放模塊，每個(gè)模塊承擔(dān)整個(gè)任務(wù)中的一部分，給每個(gè)模塊分配不同的線程數(shù)處理相應(yīng)的任務(wù)。來(lái)自上層的指令由消息接收模塊進(jìn)行處理，消息處理模塊進(jìn)行任務(wù)分配和設(shè)置結(jié)束狀態(tài)，媒體流發(fā)送模塊讀取文件并定期發(fā)送rtp流實(shí)現(xiàn)播放效果，Session及相關(guān)清除數(shù)據(jù)工作由刪除任務(wù)模塊進(jìn)行刪除。本發(fā)明提供的優(yōu)化處理方法，可達(dá)到每秒響應(yīng)150caps以上呼叫，同時(shí)并發(fā)2500路音頻或1500路音視頻文件的播放目標(biāo)。
【專利說(shuō)明】一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法，可用于多媒體彩鈴大規(guī)模并發(fā)網(wǎng)絡(luò)播放等。
【背景技術(shù)】
[0002]多媒體彩鈴業(yè)務(wù)是基于第三代移動(dòng)通信的增值業(yè)務(wù)，它可以是極具個(gè)性的視頻和音樂(lè)。用戶在撥打移動(dòng)電話過(guò)程中，如果主\被叫用戶其中之一方或者雙方均已開通了多媒體彩鈴業(yè)務(wù)，在撥通后、通話前的空閑狀態(tài)下，主叫或被叫或主\被雙方的通話終端自動(dòng)播放一段由對(duì)方專門精心制作的、內(nèi)容豐富多彩的、極具特色的多媒體彩鈴。
[0003]在電信級(jí)的多媒體彩鈴應(yīng)用時(shí)，由于其海量的用戶群體，使得機(jī)器必須要在瞬間能同時(shí)響應(yīng)大量的呼叫，并且能并發(fā)多路，而且并發(fā)的路數(shù)越多，越能降低運(yùn)營(yíng)商的成本。
[0004]如果使用傳統(tǒng)的多線程處理技術(shù)，即當(dāng)一個(gè)呼叫來(lái)時(shí)，服務(wù)器起一個(gè)線程處理這個(gè)呼叫，再需要從硬盤上讀取此文件內(nèi)容，按WAV/MP4/3GP等文件規(guī)定，依次讀取相應(yīng)的數(shù)據(jù)，再運(yùn)用rtp打包技術(shù)打包，以規(guī)定的時(shí)序進(jìn)行發(fā)送，直到上層下信令停止發(fā)送。經(jīng)過(guò)實(shí)際檢測(cè)，這種方式即使在高性能的16核的MIPS64板卡也只能支持200多路，由于Iinux線程過(guò)多，調(diào)度太頻繁而出現(xiàn)錯(cuò)誤。

【發(fā)明內(nèi)容】

[0005]本發(fā)明所要解決的問(wèn)題是克服現(xiàn)有技術(shù)存在的不足，提供一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法用于響應(yīng)多媒體彩鈴播放請(qǐng)求，實(shí)現(xiàn)性能強(qiáng)勁、有效降低設(shè)備成本的效果。
[0006]達(dá)到上述發(fā)明目的的技術(shù)方案是提供一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法，將播放系統(tǒng)分成消息接收模塊、消息處理模塊，發(fā)送模塊和刪除播放模塊，給每個(gè)模塊分配不同的線程數(shù)處理相應(yīng)的任務(wù)，包括如下步驟:
[0007](I)在消息處理模塊中設(shè)置全局會(huì)話狀態(tài)；
[0008](2)消息接收模塊將收取到的來(lái)自上層消息模塊的消息指令送至消息處理模塊；
[0009](3)消息處理模塊依據(jù)消息類型，由全局會(huì)話分配任務(wù)或設(shè)置成結(jié)束狀態(tài)；
[0010](4)發(fā)送模塊發(fā)現(xiàn)有新的會(huì)話任務(wù)后，按任務(wù)讀取指定的文件并將文件打包成音視頻媒體流發(fā)送給終端，進(jìn)行播放；每次播放的rtp包為I?3秒，每次發(fā)送結(jié)束后檢查全局會(huì)話狀態(tài)，若不需要?jiǎng)h除則回到播放隊(duì)列中；
[0011](5)刪除任務(wù)模塊發(fā)現(xiàn)有會(huì)話被設(shè)置到刪除狀態(tài)后，清除會(huì)話的任務(wù)信息及內(nèi)存資源的回收。
[0012]本發(fā)明將以往單個(gè)呼叫處理流程，服務(wù)器需要起一個(gè)線程處理這個(gè)呼叫，再需要從硬盤上讀取此文件內(nèi)容，按WAV/MP4/3GP等文件規(guī)定，依次讀取相應(yīng)的數(shù)據(jù)，再運(yùn)用rtp打包技術(shù)打包，以規(guī)定的時(shí)序進(jìn)行發(fā)送，直到上層下信令停止發(fā)送這個(gè)方法。本發(fā)明技術(shù)方案中各模塊的作用如下:
[0013](I)文件讀取模塊(1Cache模塊)，大部分彩鈴播放文件會(huì)被反復(fù)使用，只有少量需要臨時(shí)讀取，這個(gè)模塊運(yùn)用傳統(tǒng)計(jì)算機(jī)IO緩沖區(qū)原理，將常用文件可以緩存在內(nèi)存中，加快讀取速度。
[0014](2)收取上層消息的消息接收模塊(prsMsgReeeive模塊)，負(fù)責(zé)接收上層指令的XIPC消息
[0015](3)消息處理模塊(PrsMsgSwitch模塊)，負(fù)責(zé)處理XIPC消息線程，根據(jù)所下消息設(shè)置Session狀態(tài)決定Session是開始播放還是結(jié)束播放
[0016](4)發(fā)送媒體流的發(fā)送模塊(prsSendData模塊),需要播放的Session進(jìn)去隊(duì)列后，該模塊負(fù)責(zé)文件讀取、解析和RTP包的發(fā)送線程，以及將播放好的Session放入刪除隊(duì)列中。
[0017](5)刪除播放模塊(prsSessionDelete模塊),負(fù)責(zé)刪除Session及相關(guān)清除數(shù)據(jù)工作。
[0018]本發(fā)明與現(xiàn)有多線程技術(shù)，簡(jiǎn)單的完成整個(gè)操作相比，具有下列優(yōu)點(diǎn):
[0019]1、將任務(wù)精確地劃分成不同模塊，每個(gè)模塊執(zhí)行一部分任務(wù)，協(xié)作工作，大大的減少了內(nèi)部的線程數(shù)。
[0020]2、既可以保證少數(shù)工作時(shí)不過(guò)多占用系統(tǒng)資源，又可以保證大并發(fā)處理時(shí)高效及時(shí)處理響應(yīng)。
[0021]3、同樣環(huán)境中，能比簡(jiǎn)單起多線程完成整個(gè)任務(wù)的并發(fā)數(shù)增加7倍以上。
【專利附圖】

【附圖說(shuō)明】
[0022]圖1是本發(fā)明實(shí)施例提供的媒體流發(fā)送模塊處理流程圖；
[0023]圖2是本發(fā)明實(shí)施例提供的集群并發(fā)處理的流程圖。
【具體實(shí)施方式】
[0024]下面結(jié)合附圖和實(shí)施例對(duì)本發(fā)明技術(shù)方案作進(jìn)一步的闡述。
[0025]實(shí)施例1
[0026]本實(shí)施例一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法，對(duì)采用的模塊及步驟作如下具體的描述:
[0027](I)收取上層消息的消息接收模塊(prsMsgReeeive模塊)，負(fù)責(zé)接收上層指令的XIPC消息。在這個(gè)模塊更上層有專門處sip+msml信令的模塊,轉(zhuǎn)換成內(nèi)部xipc消息,通知PRS模塊進(jìn)行處理。對(duì)多媒體彩鈴來(lái)說(shuō)，就是播放指定路徑下文件和結(jié)束播放2個(gè)指令。這里在收到指令后，進(jìn)行一個(gè)初步的分發(fā)，壓進(jìn)prsMsgSwitch模塊消息隊(duì)列中。
[0028](2)消息處理模塊(prsMsgSwitch模塊)，負(fù)責(zé)處XIPC消息線程，根據(jù)所下的消息設(shè)置Session狀態(tài)決定Session是開始播放還是結(jié)束播放。如果是開始播放,調(diào)用iocache模塊將本地文件讀取壓入內(nèi)存中，將需要播放的任務(wù)壓入prsSendData模塊。如果需要結(jié)束播放，這里僅做session狀態(tài)設(shè)置。
[0029](3)發(fā)送媒體流的發(fā)送模塊(prsSendData模塊)，這個(gè)模塊是最復(fù)雜，所以線程需要分配最多。該模塊的線程在沒(méi)有任務(wù)時(shí)將休眠以避免占用cpu，直到有任務(wù)進(jìn)來(lái)開始處理，需要播放的Session進(jìn)去隊(duì)列后，此模塊只會(huì)解析和一定時(shí)間的包，就會(huì)停止發(fā)進(jìn)已經(jīng)播放隊(duì)列，當(dāng)下次再次對(duì)播放隊(duì)列處理前有一個(gè)檢查是否需要?jiǎng)h除的操作，從而響應(yīng)上層停止播放信令。當(dāng)少量播放時(shí)，這樣的出隊(duì)入隊(duì)操作其實(shí)還會(huì)增加CPU處理量，但大規(guī)模并發(fā)時(shí)就可以解決如何及時(shí)響應(yīng)上層停止播放這個(gè)問(wèn)題。
[0030](4)刪除任務(wù)模塊(prsSessionDelete模塊),負(fù)責(zé)刪除Session及相關(guān)清除數(shù)據(jù)工作。
[0031]若使用傳統(tǒng)的多線程處理技術(shù)，處理一個(gè)呼叫來(lái)時(shí)，服務(wù)器起一個(gè)線程處理這個(gè)呼叫，再需要從硬盤上讀取此文件內(nèi)容，按WAV/MP4/3GP等文件規(guī)定，依次讀取相應(yīng)的數(shù)據(jù)，再運(yùn)用rtp打包技術(shù)打包，以規(guī)定的時(shí)序進(jìn)行發(fā)送，直到上層下信令停止發(fā)送。這個(gè)缺點(diǎn)就是沒(méi)有對(duì)任務(wù)細(xì)分，在處理過(guò)程中線程繁忙程度不一，導(dǎo)致處理數(shù)量?jī)H能達(dá)到200多路。
[0032]本發(fā)明采用劃分成四大模塊，每個(gè)模塊起不同數(shù)量的線程數(shù)處理所承擔(dān)的任務(wù)，例如prsMsgSwitch模塊，若設(shè)置2個(gè)線程，每個(gè)線程定期遍歷消息隊(duì)列是否有新數(shù)據(jù)，有新數(shù)據(jù)按上述prsMsgSwitch模塊的描述進(jìn)行相應(yīng)處理,無(wú)新數(shù)據(jù)則sleep (Ius),暫時(shí)釋放出cpu使用權(quán)。經(jīng)實(shí)際測(cè)試，目前設(shè)定的線程數(shù)分別是，prsMsgReeeive模塊一個(gè)線程，prsMsgSwitch模塊兩個(gè)線程，prsSendData模塊十二個(gè)線程，prsSessionDelete模塊三個(gè)線程。由于采用模塊化的技術(shù)方案，實(shí)際隨著不同應(yīng)用場(chǎng)景還可以很方便的調(diào)整線程數(shù)。
[0033]參見附圖2，它是本實(shí)施例提供的集群并發(fā)處理的流程圖，具體處理流程如下:
[0034](I)當(dāng)上層下達(dá)的播放任務(wù)，prsMsgReeeive模塊收到這個(gè)消息后，置于模塊消息隊(duì)列中，它的任務(wù)即完成，處理下一個(gè)消息。
[0035](2) prsMsgSwitch模塊任意一個(gè)線程檢測(cè)到新壓入的處理消息，進(jìn)行相應(yīng)的處理，任務(wù)壓入prsSendData模塊。
[0036](3)prsSendData模塊檢測(cè)到相應(yīng)的任務(wù)，按上面描述進(jìn)行發(fā)送rtp包操作，即給指定的用戶發(fā)送多媒體彩鈴。
[0037](4)當(dāng)用戶通話開始時(shí)，運(yùn)營(yíng)商會(huì)終止多媒體彩鈴播放，經(jīng)過(guò)一系列處理，上層下停止播放信令，prsMsgReeeive模塊收到這個(gè)消息后,壓入prsMsgSwitch模塊消息隊(duì)列中。
[0038](5)prsMsgSwitch模塊任意一個(gè)線程檢測(cè)到新壓入的停止播放消息，找到相應(yīng)的任務(wù)，將其狀態(tài)置為deleting狀態(tài)。
[0039](6)由圖1所示，prsSendData模塊中的線程，每次只是發(fā)送一段時(shí)間即將任務(wù)重新壓入隊(duì)尾，這樣做的好處即可以避免后續(xù)播放任務(wù)長(zhǎng)時(shí)間無(wú)響應(yīng)，又解決了這里停止播放問(wèn)題。每次重新獲取任務(wù)時(shí)，會(huì)檢測(cè)其狀態(tài)，當(dāng)狀態(tài)為deleting時(shí),這個(gè)任務(wù)被壓入prsSessionDelete 模塊。
[0040](7)prsSessionDelete模塊任意一個(gè)線程檢測(cè)到新壓入的刪除任務(wù)，進(jìn)行相應(yīng)處理。
[0041]采用本發(fā)明技術(shù)方案，在處理單路時(shí)明顯增加了處理流程，但任務(wù)量增加后，所有線程將開始全力工作，由于不同階段處理的復(fù)雜度不一樣，因此，在本實(shí)施例中，prsMsgReeeive模塊設(shè)置一個(gè)線程,prsMsgSwitch模塊設(shè)置兩個(gè)線程,prsSendData模塊設(shè)置十二個(gè)線程，prsSessionDelete模塊設(shè)置三個(gè)線程，既保證了系統(tǒng)cpu同時(shí)處于高效運(yùn)作狀態(tài)，但又沒(méi)有啟動(dòng)過(guò)多的線程增加系統(tǒng)調(diào)度線程的復(fù)雜度。由于本發(fā)明技術(shù)方案的采用，使原來(lái)只能支持200多路，達(dá)到了能夠每秒響應(yīng)150caps以上呼叫，同時(shí)并發(fā)2500路音頻或1500路音視頻文件播放的設(shè)計(jì)目標(biāo)。[0042]經(jīng)測(cè)試，采用本發(fā)明技術(shù)方案，可在16核的MIPS64板卡上實(shí)現(xiàn)單卡每秒響應(yīng)156次呼叫，同時(shí)并發(fā)2500路音頻或1500路音視頻文件的播放，有效的降低了設(shè)備成本。程序是基于Linux上開發(fā)的，可以輕松移植到其他Linux平臺(tái)機(jī)器，根據(jù)機(jī)器的CPU核數(shù)迅速調(diào)整模塊的線程數(shù)，同樣實(shí)現(xiàn)高效并發(fā)播放。
【權(quán)利要求】
1.一種集群并發(fā)發(fā)送網(wǎng)絡(luò)媒體流的方法，其特征在于:將播放系統(tǒng)分成消息接收模塊、消息處理模塊，發(fā)送模塊和刪除播放模塊，給每個(gè)模塊分配不同的線程數(shù)處理相應(yīng)的任務(wù)，包括如下步驟: (1)在消息處理模塊中設(shè)置全局會(huì)話狀態(tài)； (2)消息接收模塊將收取到的來(lái)自上層消息模塊的消息指令送至消息處理模塊； (3)消息處理模塊依據(jù)消息類型，由全局會(huì)話分配任務(wù)或設(shè)置成結(jié)束狀態(tài)； (4)發(fā)送模塊發(fā)現(xiàn)有新的會(huì)話任務(wù)后，按任務(wù)讀取指定的文件并將文件打包成音視頻媒體流發(fā)送給終端，進(jìn)行播放；每次播放的rtp包為I?3秒，每次發(fā)送結(jié)束后檢查全局會(huì)話狀態(tài)，若不需要?jiǎng)h除則回到播放隊(duì)列中； (5)刪除任務(wù)模塊發(fā)現(xiàn)有會(huì)話被設(shè)置到刪除狀態(tài)后，清除會(huì)話的任務(wù)信息及內(nèi)存資源的回收。
【文檔編號(hào)】H04L29/06GK103957221SQ201410211224
【公開日】2014年7月30日 申請(qǐng)日期:2014年5月20日 優(yōu)先權(quán)日:2014年5月20日
【發(fā)明者】周翔 申請(qǐng)人:艾諾通信系統(tǒng)（蘇州）有限責(zé)任公司