專利名稱：基于nat的udp流媒體服務(wù)器的網(wǎng)關(guān)穿透方法
技術(shù)領(lǐng)域：
本發(fā)明屬于網(wǎng)絡(luò)多媒體技術(shù)領(lǐng)域，涉及一種基于NAT的UDP流媒體服務(wù)器的網(wǎng)關(guān)穿透方法。具體地說，主要涉及在網(wǎng)絡(luò)多媒體中，使流媒體服務(wù)器ClearServer可以識別內(nèi)網(wǎng)客戶端的IP(網(wǎng)絡(luò)協(xié)議)地址和端口號，將服務(wù)器端的多媒體數(shù)據(jù)能夠順利發(fā)送到客戶端的方法，從而實時有效的在因特網(wǎng)中傳送多媒體信息。
背景技術(shù)：
流媒體(Media Streaming)技術(shù)是指支持多媒體數(shù)據(jù)流通過網(wǎng)絡(luò)從服務(wù)器向客戶端傳送，接收方邊接收邊播放的技術(shù)。流媒體應(yīng)用通常要求視頻和音頻連續(xù)、清晰和實時地播放，這就對網(wǎng)絡(luò)服務(wù)提出了要求1)必須實時傳輸數(shù)據(jù)，僅能夠容忍少量的延遲(數(shù)百毫秒)；2)傳送數(shù)據(jù)相對可靠，容忍一定數(shù)量的數(shù)據(jù)丟失；3)確保一定的帶寬，以保證傳輸?shù)臄?shù)據(jù)量能夠?qū)崟r地播放。
Internet(因特網(wǎng))給網(wǎng)絡(luò)應(yīng)用程序提供兩種服務(wù)TCP(傳輸控制協(xié)議)和UDP(用戶數(shù)據(jù)報協(xié)議)。TCP通過確認和重傳機制保證數(shù)據(jù)無錯順序地傳送，同時采用擁塞控制策略和發(fā)送速率控制解決傳輸中的擁塞問題以及發(fā)送速率與接受速率不匹配問題。但是TCP采用上述控制策略的時候卻犧牲了數(shù)據(jù)的傳輸速度，所以對于傳輸數(shù)據(jù)量較大的流媒體應(yīng)用來說，采用TCP傳輸難以保證數(shù)據(jù)傳輸?shù)膶崟r性。而UDP傳輸方式?jīng)]有TCP的擁塞控制和發(fā)送速率控制，也沒有提供數(shù)據(jù)傳輸?shù)目煽啃员ＷC，但是卻保證了傳輸?shù)乃俣?，滿足了流媒體應(yīng)用中的關(guān)鍵因素——實時性，所以越來越被流媒體應(yīng)用系統(tǒng)所采納。
ClearServer是一種新興的UDP流媒體服務(wù)器，實現(xiàn)了視頻質(zhì)量和發(fā)送速率的控制以及符合工業(yè)標準的擁塞控制以此大幅度的提高流媒體服務(wù)質(zhì)量，并有自適應(yīng)網(wǎng)絡(luò)帶寬的傳輸功能，可按網(wǎng)絡(luò)實際狀況調(diào)節(jié)媒體傳輸碼率，解決了流媒體傳輸中的時延問題，即采用UDP傳輸協(xié)議能夠獲得較高的傳輸率。ClearServer服務(wù)器端接收到包含客戶端請求信息的RTSP(Real Time Streaming Protocol實時流協(xié)議)數(shù)據(jù)包請求之后，解析數(shù)據(jù)包取得客戶端的IP地址和端口號，根據(jù)取得的客戶端IP地址和端口號，將客戶請求的多媒體數(shù)據(jù)發(fā)送到客戶端。但是，這種接收和發(fā)送機制存在這樣的一個問題如果一臺intranet(內(nèi)網(wǎng))機器在點播ClearServer的時候，由于內(nèi)網(wǎng)機器IP地址對于普通的Internet上的機器而言是不可知的，即對于流媒體服務(wù)器ClearServer來說，包含客戶端請求信息的RTSP數(shù)據(jù)包中的IP地址和端口號是不可識別的，根據(jù)這個數(shù)據(jù)包中的IP地址和端口號，ClearServer無法將客戶端請求的流媒體數(shù)據(jù)發(fā)到客戶端。
由于UDP傳輸協(xié)議是一個面向無連接的服務(wù)，即沒有在兩個進程之間建立連接的初始“握手”階段，所以在一個進程想要往另一個進程發(fā)送一批字節(jié)的時候，發(fā)送方進程必須將目的進程的地址加入到發(fā)送的字節(jié)中。當(dāng)點播ClearServer的時候，客戶端發(fā)送的RTSP請求字節(jié)中包含客戶端的IP地址和端口號信息。當(dāng)RTSP請求到達ClearServer后，ClearServer將它解析，得到客戶端的IP地址和端口號信息，然后服務(wù)器回應(yīng)客戶端的RTSP請求。在向客戶端發(fā)送UDP流媒體數(shù)據(jù)之前，先對要發(fā)送的流媒體數(shù)據(jù)進行“包裝”，以解析RTSP請求所得的客戶端IP地址和端口為發(fā)送目的地，然后將UDP數(shù)據(jù)包發(fā)出。
在內(nèi)網(wǎng)中，任何一臺計算機的IP地址僅僅是一個臨時的IP地址，即內(nèi)網(wǎng)外部的機器無法識別這個IP地址。所以內(nèi)網(wǎng)的某臺計算機點播ClearServer服務(wù)器的時候，客戶端發(fā)送到服務(wù)器端的分組中包含的IP地址實際上“虛擬”的，以這個IP地址為發(fā)送目的地的UDP數(shù)據(jù)包無法到達客戶端。所以，必須找出一種方法，找到內(nèi)網(wǎng)客戶端的“地址”，使得服務(wù)器端能夠根據(jù)這個“地址”能找到客戶端，從而將流媒體數(shù)據(jù)發(fā)送到客戶端。

發(fā)明內(nèi)容
本發(fā)明的目的在于提供一種使流媒體服務(wù)器Clear Media Server可以識別內(nèi)網(wǎng)客戶端的IP地址和端口號，將服務(wù)器端的多媒體數(shù)據(jù)順利發(fā)送到客戶端的方法，我們稱其為ClearNat方法。目前網(wǎng)絡(luò)上運行的網(wǎng)關(guān)普遍都提供NAT服務(wù)，即網(wǎng)絡(luò)地址轉(zhuǎn)換。本發(fā)明適用于穿透提供NAT服務(wù)的網(wǎng)關(guān)，以下稱之為NAT服務(wù)器。本方法需要為內(nèi)網(wǎng)的機器的客戶端建立內(nèi)網(wǎng)IP地址、端口與NAT服務(wù)器IP地址、端口的映射，以使流媒體服務(wù)器ClearServer能將媒體數(shù)據(jù)穿透NAT服務(wù)器發(fā)送到內(nèi)網(wǎng)機器的播放器上。該方法的計算復(fù)雜度較低，效果好，對主控服務(wù)器的其他應(yīng)用進程沒有影響，且在流媒體服務(wù)器ClearServer中能支持大的內(nèi)網(wǎng)并發(fā)用戶的使用。
對于流媒體服務(wù)器來說處于內(nèi)網(wǎng)的客戶端所在計算機的IP地址、端口是不可見的，也就是說，通過RTSP交互，服務(wù)器ClearServer得到的內(nèi)網(wǎng)IP地址、端口其實是不可用的，即無法將點播節(jié)目的UDP數(shù)據(jù)包發(fā)送到處于內(nèi)網(wǎng)的客戶端。而網(wǎng)關(guān)提供的NAT服務(wù)使得服務(wù)器有途經(jīng)正確得發(fā)送UDP數(shù)據(jù)包。當(dāng)內(nèi)網(wǎng)的計算機向外網(wǎng)發(fā)送UDP數(shù)據(jù)包時，NAT服務(wù)器會記錄內(nèi)網(wǎng)計算機的IP地址、端口(記為A、B)，并在NAT服務(wù)器上隨即選擇一個端口C，轉(zhuǎn)發(fā)從內(nèi)網(wǎng)發(fā)送過來的UDP數(shù)據(jù)包，并將NAT服務(wù)器上的端口C與內(nèi)網(wǎng)IP地址A、端口B組成一個映射，此后，從外網(wǎng)發(fā)回給NAT服務(wù)器端口C的UDP數(shù)據(jù)包都會被轉(zhuǎn)發(fā)到內(nèi)網(wǎng)IP地址A的端口B。因此，只要UDP流媒體服務(wù)器將數(shù)據(jù)包發(fā)向NAT服務(wù)器上正確的端口，那么UDP數(shù)據(jù)包就能夠被轉(zhuǎn)發(fā)到處于內(nèi)網(wǎng)的客戶端。關(guān)鍵在于，要讓UDP流媒體服務(wù)器ClearServer建立內(nèi)網(wǎng)IP地址、端口與NAT服務(wù)器IP地址、端口的映射。通過運行在客戶端與服務(wù)器端兩方的程序的配合，能夠做到這一點，這也就是ClearNat方法的基本原理。據(jù)此，稱本發(fā)明為基于NAT的UDP流媒體服務(wù)器的網(wǎng)關(guān)穿透方法。
本發(fā)明的具體工作步驟如下首先，需要一個OCX(ActiveX控件)運行在客戶端瀏覽的點播網(wǎng)頁上。當(dāng)用戶點擊網(wǎng)頁上的點播鏈接后，由網(wǎng)頁告知OCX，用戶名信息、用戶點播影片名信息和流媒體服務(wù)器ClearServer的IP地址。OCX根據(jù)這些信息構(gòu)建UDP數(shù)據(jù)包，其中數(shù)據(jù)段的內(nèi)容包括用戶的內(nèi)網(wǎng)IP地址、內(nèi)網(wǎng)UDP接收端口和點播的節(jié)目名。內(nèi)網(wǎng)UDP接收端口其實就是用戶的視頻播放器等待接收UDP數(shù)據(jù)包的端口，OCX可以根據(jù)不同播放器的不同配置來動態(tài)決定端口號(在RTSP協(xié)議下，通常為4個連續(xù)的端口)。UDP數(shù)據(jù)包構(gòu)建完成后，發(fā)送到流媒體服務(wù)器ClearServer的IP地址(實際實現(xiàn)中約定端口8888，非強制)。每個UDP數(shù)據(jù)包對應(yīng)一個端口映射，四個連續(xù)的端口映射形成一組。
然后，ClearServer服務(wù)器端有一個clearnat進程，負責(zé)接收和處理OCX發(fā)送過來UDP數(shù)據(jù)包。在收到一個UDP數(shù)據(jù)包后，先解析UDP協(xié)議頭部，獲得UDP數(shù)據(jù)包來源的IP地址和端口，也就是NAT服務(wù)器的IP地址和端口。接著解析UDP數(shù)據(jù)段，獲得用戶的內(nèi)網(wǎng)IP地址和端口(用戶名和節(jié)目名是用于判斷這個UDP數(shù)據(jù)包是否反映了最新的信息，以防止產(chǎn)生重復(fù)和錯誤的映射關(guān)系)。再將NAT服務(wù)器的IP地址和端口與內(nèi)網(wǎng)IP地址和端口組成一對端口映射關(guān)系，并記錄下來，然后接著接收下一個UDP數(shù)據(jù)包。當(dāng)集齊4個連續(xù)的端口映射后，就把它們作為一組完整的端口映射關(guān)系，并將完整的每一組映射關(guān)系，通過IPC(進程間通信)方式傳遞給ClearServer的主控服務(wù)器。主控服務(wù)器接收映射關(guān)系組，并保存在關(guān)系組記錄表中。
最后，當(dāng)ClearServer主控服務(wù)器需要向客戶端發(fā)送UDP數(shù)據(jù)包的時候，先去查看映射關(guān)系組記錄表。對于來自于內(nèi)網(wǎng)的客戶端點播，服務(wù)器就用映射關(guān)系中的NAT地址、端口替換掉客戶端所在計算機的內(nèi)網(wǎng)IP地址、端口。即，以NAT IP地址、端口作為UDP數(shù)據(jù)包的發(fā)送目的地。
這樣，ClearServer實際上就會向NAT服務(wù)器發(fā)送UDP數(shù)據(jù)包，而當(dāng)數(shù)據(jù)包到達NAT服務(wù)器后，就會被正確得轉(zhuǎn)發(fā)到處于內(nèi)網(wǎng)的客戶端。讓內(nèi)網(wǎng)用戶也能享受視頻點播的服務(wù)。


圖1是本發(fā)明的方法結(jié)構(gòu)圖。
圖2是OCX的工作流程圖。
圖3是clearnat進程的工作流程圖。
圖4是主控服務(wù)器中處理映射關(guān)系并進行地址端口替換的功能模塊的工作流程圖。
具體實施例方式
為了解決現(xiàn)有技術(shù)中的問題，本發(fā)明提供了一種新穎的使UDP數(shù)據(jù)包順利穿透網(wǎng)關(guān)(NAT服務(wù)器)的方法，即ClearNat方法，參見圖1。圖1描述的是ClearNat方法的結(jié)構(gòu)。圖中圓圈的標號反映的是數(shù)據(jù)流程的順序。IP地址和端口僅僅是示例性的。
下面詳細說明ClearNat方法的工作流程。
第一，本發(fā)明需要在內(nèi)網(wǎng)客戶端的點播網(wǎng)頁上運行一個OCX。OCX的工作流程參見圖2。當(dāng)用戶進行VOD(Video On Demand)點播時，首先會點擊視頻點播網(wǎng)頁上某一個節(jié)目的鏈接。這樣，網(wǎng)頁就會把一些必要的信息傳遞給在網(wǎng)頁上運行的OCX，對應(yīng)圖中步驟202。信息包括用戶名、點播的節(jié)目名和點播服務(wù)器ClearServer的IP地址。OCX接收到這些信息后，就到了步驟204。OCX需要確定本機播放器監(jiān)聽接收UDP視頻數(shù)據(jù)的端口。一般而言，對于Apple公司的QuickTime Player，會以6970為起始，每4個連續(xù)的端口為一個播放器工作。例如，一臺計算機上，第一個QuickTime Player使用端口6970-6973，第二個QuickTime Player使用端口6974-6977，以此類推。對于MicroSoft公司的WindowsMedia Player，可以為它指定接收UDP視頻數(shù)據(jù)的端口，OCX每次動態(tài)地選擇一組空閑的端口供Windows Media Player使用。這樣，OCX就根據(jù)用戶使用的播放器確定本機UDP數(shù)據(jù)接收端口，并綁定。接著進入步驟206，OCX將確定的本機端口號，連同本機IP地址、用戶名、點播節(jié)目名寫入UDP數(shù)據(jù)包的數(shù)據(jù)段中。每個端口對應(yīng)一個UDP數(shù)據(jù)包，4個合為一組。最后，步驟208中，根據(jù)網(wǎng)頁處得來的ClearServer服務(wù)器的IP地址，將步驟206中構(gòu)建的UDP數(shù)據(jù)包發(fā)向ClearServer的8888端口(實際實現(xiàn)中的約定)?？紤]到內(nèi)網(wǎng)到外網(wǎng)的鏈路一般環(huán)境不會很好，UDP可能會出現(xiàn)丟包，則在步驟208中，可以采取冗余發(fā)送的策略，將每個UDP數(shù)據(jù)包發(fā)送多遍，可以有效降低丟包率。實際上，由復(fù)旦大學(xué)(內(nèi)網(wǎng)環(huán)境)發(fā)向清華大學(xué)(外網(wǎng)環(huán)境)，每個UDP數(shù)據(jù)包發(fā)送3遍就幾乎可以確保沒有丟包。
第二，在UDP流媒體視頻點播服務(wù)器ClearServer端，運行一個名為clearnat的進程。它的功能是接收、處理OCX發(fā)過來的UDP數(shù)據(jù)包，并將完整的、最新的端口映射關(guān)系組發(fā)送給主控進程。clearnat的工作流程參見圖3。步驟302中clearnat啟動并在約定的8888端口監(jiān)聽，當(dāng)接收到一個UDP數(shù)據(jù)包后，就開始處理。步驟304，解析UDP協(xié)議頭，獲得NAT服務(wù)器的IP地址和端口；解析UDP數(shù)據(jù)段，獲得用戶名、點播節(jié)目名、內(nèi)網(wǎng)IP地址和端口。如果UDP協(xié)議頭中的IP地址與UDP數(shù)據(jù)段中的內(nèi)網(wǎng)IP地址相同，則說明該用戶是在外網(wǎng)上進行點播，不需要用到本發(fā)明的方法，程序繼續(xù)等待下一個UDP數(shù)據(jù)包。如果是內(nèi)網(wǎng)點播，則將NAT服務(wù)器的IP地址和端口與內(nèi)網(wǎng)的IP地址和端口組成一個映射關(guān)系。然后查詢自己維護的映射關(guān)系記錄表(步驟306)，如果有重復(fù)的記錄，說明這是個冗余的UDP數(shù)據(jù)包，則簡單地丟棄它；否則再根據(jù)用戶名、點播節(jié)目名來判斷這個映射關(guān)系的時效性(步驟308)，即是否反映了最新的用戶點播請求，是，則將這個映射關(guān)系記錄(步驟310)；否，則簡單丟棄。進入步驟312，每次記錄下一個映射關(guān)系，就去檢查整個映射關(guān)系記錄表，看看是否集齊完整的一組映射關(guān)系，即，同一個內(nèi)網(wǎng)IP地址上的4個連續(xù)端口的映射關(guān)系。如果沒有，就繼續(xù)等待下一個UDP數(shù)據(jù)包的到來；如果得到完整的一組映射關(guān)系，就將這一映射關(guān)系組，通過IPC(Inter-Process Communication進程間通信)方式傳遞給主控服務(wù)器(步驟314)，然后繼續(xù)等待UDP數(shù)據(jù)包。
第三，在主控服務(wù)器上，有一個功能模塊，負責(zé)處理從clearnat進程發(fā)送過來的信息，并在服務(wù)器發(fā)送UDP數(shù)據(jù)前進行必要的IP地址和端口的替換。圖4描述了這個功能模塊的流程。它在主控服務(wù)器的消息循環(huán)中等待來自clearnat的信息(步驟402)，接收到clearnat發(fā)送過來的映射關(guān)系組信息后(步驟404)，首先到自己的映射關(guān)系組記錄表中查詢是否有相同的記錄(步驟406)，如果有相同的記錄則丟棄此映射關(guān)系組，繼續(xù)等待映射關(guān)系組信息，如果沒有則把此記錄添加到記錄表中(步驟408)。每當(dāng)有客戶端的點播請求到達主控服務(wù)器時(步驟410)，就去映射關(guān)系組記錄表中查詢，看看是否有對應(yīng)該用戶的映射關(guān)系記錄(步驟412)，如果沒有，則表明該用戶是普通的外網(wǎng)點播客戶端，無需使用本發(fā)明的方法，(步驟414)；如果有，則表明該用戶是通過內(nèi)網(wǎng)點播的客戶端，那么在向這個客戶端發(fā)送UDP數(shù)據(jù)的時候，就用映射關(guān)系組中的NAT服務(wù)器IP地址和端口，替換內(nèi)網(wǎng)IP地址和端口。
本發(fā)明的性能如下復(fù)雜度N個客戶端，處理NAT信息所需要多做的計算包括加減計算和查表計算計算復(fù)雜度為O(N2)。
處理時間ClearNat信息處理中主要是對信息表的查詢和處理操作。表1是信息表查詢操作所需的CPU時間進行測試。測試環(huán)境處理器迅馳1.5G，內(nèi)存512M，操作系統(tǒng)WindowsXP。

表1 查詢表操作所需CPU時間主控進程對NAT端口映射表的查詢和處理等操作所需時間非常少，即使NAT端口映射表中的節(jié)點數(shù)目達到100000，做一次查詢和處理所需的時間也基本上會小于1ms。
對并發(fā)數(shù)的影響由于查表操作所需時間比較少，只有客戶端達到100000以上時每次查表操作所需時間才超過10ms。當(dāng)N＝1000000時，這對于主控進程(Main Process)的調(diào)度也許就會帶來一些困難。但是這個并發(fā)數(shù)是在假定每個客戶都是內(nèi)網(wǎng)用戶，并通過NAT服務(wù)器進行視頻點播。在實際應(yīng)用中，服務(wù)器的客戶肯定有很大一部分是通過公網(wǎng)直接連接到流媒體服務(wù)器上進行視頻點播的。
總之，采用本發(fā)明所述的ClearNat方法，可以讓流媒體服務(wù)器ClearServer發(fā)送的UDP數(shù)據(jù)包順利穿透網(wǎng)關(guān)(NAT服務(wù)器)，為處于內(nèi)網(wǎng)的客戶端提供優(yōu)質(zhì)的視頻點播服務(wù)。
本公開的方式描述了本公開和本發(fā)明的最佳模式，應(yīng)該理解并且認識到，有許多等效于在此公開的示例性實施例的方式，并且在不脫離本發(fā)明的范圍和精神的情況下可以進行修改和變形，本發(fā)明不受示例性實施例的限制而只受附加的權(quán)利要求的限制。
權(quán)利要求
1.一種使流媒體服務(wù)器ClearServer可以識別內(nèi)網(wǎng)客戶端的IP地址和端口號，將服務(wù)器端的多媒體數(shù)據(jù)順利發(fā)送到客戶端的方法，其特征在于具體步驟如下a.將一個OCX運行在客戶端瀏覽的點播網(wǎng)頁上；當(dāng)用戶點擊網(wǎng)頁上的點播鏈接后，由網(wǎng)頁告知OCX，用戶名信息、用戶點播節(jié)目的信息和流媒體服務(wù)器ClearServer的IP地址；OCX根據(jù)這些信息構(gòu)建UDP數(shù)據(jù)包，其中數(shù)據(jù)段的內(nèi)容包括用戶的內(nèi)網(wǎng)IP地址、內(nèi)網(wǎng)UDP接收端口和點播的節(jié)目名稱；UDP數(shù)據(jù)包構(gòu)建完成后，就會發(fā)送到流媒體服務(wù)器ClearServer的IP地址(實際實現(xiàn)中約定端口8888，非強制)。每個UDP數(shù)據(jù)包對應(yīng)一個端口映射，四個連續(xù)的端口映射形成一組；b.ClearServer服務(wù)器端有一個clearnat進程，負責(zé)接收和處理OCX發(fā)送過來UDP數(shù)據(jù)包；在收到一個UDP數(shù)據(jù)包后，解析UDP協(xié)議頭部，獲得UDP數(shù)據(jù)包來源的IP地址和端口；解析UDP數(shù)據(jù)段，獲得內(nèi)網(wǎng)的IP地址和端口；clearnat將完整的一組映射關(guān)系通過IPC(進程間通信)方式發(fā)送給主控服務(wù)器；c.主控服務(wù)器接收映射關(guān)系組，并保存在映射關(guān)系組記錄表中；當(dāng)主控服務(wù)器需要向客戶端發(fā)送UDP數(shù)據(jù)包的時候，先去查看映射關(guān)系組記錄表，對于來自于內(nèi)網(wǎng)的客戶端點播，服務(wù)器就用映射關(guān)系中的NAT地址、端口替換掉客戶端所在計算機的內(nèi)網(wǎng)IP地址、端口。
2.如權(quán)利要求1所述的方法，其特征在于，在步驟b中，包括將NAT服務(wù)器的IP地址和端口和內(nèi)網(wǎng)IP地址和端口組成一對端口映射關(guān)系，并記錄下來，然后接著接收下一個UDP數(shù)據(jù)包；當(dāng)集齊4個連續(xù)的端口映射后，就把它們作為一組完整的端口映射關(guān)系，并將完整的每一組映射關(guān)系，通過IPC(進程間通信)方式傳遞給ClearServer的主控服務(wù)器進程。
全文摘要
本發(fā)明屬于網(wǎng)絡(luò)多媒體技術(shù)領(lǐng)域，具體是使流媒體服務(wù)器發(fā)送的UDP(用戶數(shù)據(jù)報協(xié)議)數(shù)據(jù)包穿透網(wǎng)關(guān)的一種方法，即ClearNat方法，。根據(jù)該方法流媒體服務(wù)器ClearServer可以識別內(nèi)網(wǎng)客戶端的IP地址和端口，將NAT服務(wù)器的IP地址和端口與內(nèi)網(wǎng)客戶端的IP地址和端口做一個映射，通過替換IP地址和端口，將服務(wù)器端的UDP數(shù)據(jù)發(fā)送到NAT服務(wù)器，再由NAT服務(wù)器把數(shù)據(jù)轉(zhuǎn)發(fā)到處于內(nèi)網(wǎng)的客戶端，實現(xiàn)穿透網(wǎng)關(guān)，從而有效的在因特網(wǎng)中實時傳送多媒體信息。該方法的計算復(fù)雜度較低，效果很好，對主控服務(wù)器的其他應(yīng)用進程沒有影響，且在流媒體服務(wù)器ClearServer中能支持大的內(nèi)網(wǎng)并發(fā)用戶的使用。
文檔編號H04L12/56GK1694430SQ200510026160
公開日2005年11月9日 申請日期2005年5月25日 優(yōu)先權(quán)日2005年5月25日
發(fā)明者葉德建, 孫澔峻, 張佐 申請人:復(fù)旦大學(xué)