基于IP多播與JMF技術(shù)的網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)設(shè)計(jì)研究

賈長(zhǎng)云，陶祥亞，楊 成

1淮海工學(xué)院信息中心，江蘇 連云港 222005;2江蘇師范大學(xué)信息傳播學(xué)院，江蘇 徐州 221009

隨著計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)、多媒體技術(shù)、計(jì)算機(jī)視覺和模擬識(shí)別技術(shù)的發(fā)展，各種以數(shù)字化、智能化為特點(diǎn)的網(wǎng)絡(luò)教學(xué)系統(tǒng)應(yīng)運(yùn)而生。網(wǎng)絡(luò)教學(xué)相比傳統(tǒng)教學(xué)模式，更能培養(yǎng)學(xué)習(xí)者信息獲取、加工、分析、創(chuàng)新、利用、交流的能力。網(wǎng)絡(luò)教學(xué)通常是通過教學(xué)視頻廣播、視頻點(diǎn)播、視頻答疑、Web教材、多媒體課件、BBS論壇、聊天室(教學(xué)討論區(qū))、E-mail等內(nèi)容和方式來實(shí)現(xiàn)教學(xué)目標(biāo)的教學(xué)形式。網(wǎng)絡(luò)教學(xué)系統(tǒng)在教學(xué)內(nèi)容呈現(xiàn)和工具手段施行過程中，在傳者和授者之間有大量的數(shù)據(jù)需要處理和傳輸，選擇什么樣的數(shù)據(jù)傳輸技術(shù)將決定網(wǎng)絡(luò)教學(xué)系統(tǒng)數(shù)據(jù)傳輸?shù)男屎途W(wǎng)絡(luò)教學(xué)的效益。依托IP多播技術(shù)和SUN公司提供的JMF(java media framework)開源多媒體開發(fā)包能設(shè)計(jì)出對(duì)等的、基于IP多播的、遠(yuǎn)程網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)，可滿足網(wǎng)絡(luò)教學(xué)多流、大數(shù)據(jù)的要求。

1 IP多播技術(shù)與JMF技術(shù)簡(jiǎn)介

1.1 IP 多播技術(shù)

該技術(shù)可實(shí)現(xiàn)用戶終端到一個(gè)“主機(jī)組”的IP數(shù)據(jù)包的傳送，主機(jī)組是由零個(gè)或多個(gè)用同一IP目的地址標(biāo)識(shí)的主機(jī)集合。它是一個(gè)對(duì)等多播系統(tǒng)，系統(tǒng)實(shí)施時(shí)所使用的目的地址通常由一個(gè)D類地址(224.0.0.0 ～239.255.255.255)和使用相同多播地址的所有主機(jī)構(gòu)成一個(gè)主機(jī)組。主機(jī)組是開放的，任一主機(jī)均可自由加入或退出，它不必知道組內(nèi)其他主機(jī)是否存在，這符合遠(yuǎn)程教學(xué)的特點(diǎn)。與傳統(tǒng)的點(diǎn)到點(diǎn)模式(如TCP/IP協(xié)議)單點(diǎn)播送相比，大大減輕了網(wǎng)路負(fù)載，提高了數(shù)據(jù)的傳輸效率，特別適合于網(wǎng)絡(luò)教學(xué)“流”式資源數(shù)據(jù)的傳輸，有利于網(wǎng)絡(luò)教學(xué)中常用的數(shù)據(jù)資源(包括不同格式的圖片、視頻、音頻等)有效的、可靠的傳輸和在傳輸系統(tǒng)兩端的實(shí)時(shí)顯示。另外，IP多播技術(shù)是標(biāo)準(zhǔn)的IP網(wǎng)絡(luò)層協(xié)議的擴(kuò)展，多播的數(shù)據(jù)包被傳遞到目的主機(jī)組的所有成員，同常規(guī)單點(diǎn)傳輸IP數(shù)據(jù)包一樣可靠，主機(jī)組中的成員在位置和數(shù)量上都沒有限制，一個(gè)主機(jī)組可同時(shí)是一個(gè)以上主機(jī)組成員［1］。

1.2 JMF 技術(shù)

JMF是由SUN公司開發(fā)的專門用于處理視、音頻媒體的擴(kuò)展應(yīng)用開發(fā)包，它集成了對(duì)視、音頻的采集、編碼、傳輸、播放等功能。JMF包括JMF API和RTP API兩個(gè)部分。JMF API主要由一些接口組成，這些接口定義了用于捕捉、處理和播放媒體對(duì)象的行為和交互。使用JMF API能方便地開發(fā)用于實(shí)時(shí)媒體數(shù)據(jù)的捕捉處理、存儲(chǔ)的小程序和應(yīng)用程序，并在已存在的框架上集成新的功能，從而實(shí)現(xiàn)新的解決方案［2］。RTP API是一種提供端對(duì)端傳輸服務(wù)的實(shí)時(shí)傳輸協(xié)議，用來支持在單目標(biāo)廣播和多目標(biāo)廣播網(wǎng)絡(luò)服務(wù)中傳輸實(shí)時(shí)數(shù)據(jù)，而實(shí)時(shí)數(shù)據(jù)的傳輸則由RTCP(實(shí)時(shí)傳輸控制協(xié)議)來監(jiān)視和控制，RTCP用來監(jiān)視服務(wù)質(zhì)量和傳送有關(guān)參與者的信息，RTP和RTCP協(xié)議是配合使用的，它們能有效地反饋和以最小的開銷實(shí)現(xiàn)傳輸效率最佳，RTP通常是通過UDP協(xié)議進(jìn)行傳輸?shù)?，需要發(fā)送的多媒體數(shù)據(jù)塊(聲音或視頻)經(jīng)過壓縮編碼處理后，先送給RTP封裝成為RTP分組，然后再裝入U(xiǎn)DP用戶數(shù)據(jù)包，并向下遞交給IP層［3］。

2 數(shù)據(jù)傳輸系統(tǒng)的功能模塊設(shè)置與結(jié)構(gòu)

2.1 網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)功能模塊設(shè)置

為滿足網(wǎng)絡(luò)教學(xué)系統(tǒng)多流、大數(shù)據(jù)的要求，在網(wǎng)絡(luò)教學(xué)平臺(tái)建設(shè)時(shí)可在底層利用IP多播和JMF技術(shù)設(shè)置“多播文件分發(fā)、多播圖片傳輸、多播實(shí)時(shí)流媒體處置和多播在線交流”四大傳輸功能模塊，它們的功能設(shè)計(jì)目標(biāo)分別如下［4］。

2.1.1 多播文件分發(fā)模塊 文件分發(fā)模塊利用IP多播技術(shù)實(shí)現(xiàn)了任何類型辦公文件(.txt、.doc、.pdf、.xls、.ppt等)的傳輸和接收組裝，并且根據(jù)文件類型的不同，通過程序語(yǔ)句能調(diào)用操作系統(tǒng)中相應(yīng)的軟件來實(shí)時(shí)打開顯示這些辦公文件。

2.1.2 多播圖片傳輸模塊 圖片傳輸模塊能實(shí)現(xiàn)任何格式圖片(.bmp、.jpg、.gif、.png 等)的傳輸和接收組裝，并且能根據(jù)圖片的實(shí)際大小、圖片名稱組成新的窗口來實(shí)時(shí)顯示所傳輸?shù)膱D片。由于Java不支持后綴名為.bmp格式的圖片的處理，故得不到.bmp格式圖片的高度和寬度，該研究將通過程序語(yǔ)句調(diào)用操作系統(tǒng)中的打開圖片軟件來實(shí)時(shí)對(duì)后綴名為.bmp格式圖片的打開顯示，而對(duì)于后綴名為.gif格式的動(dòng)態(tài)圖片，傳輸系統(tǒng)在接收顯示后仍然能動(dòng)態(tài)顯示。

2.1.3 多播實(shí)時(shí)流媒體處置模塊 利用該模塊能對(duì)網(wǎng)絡(luò)教學(xué)常見類型的流媒體文件(.mov、.wav、.au、.mpg、.mpeg等)進(jìn)行處理，再利用 IP 多播技術(shù)和JMF技術(shù)即可實(shí)現(xiàn)對(duì)流媒體多媒體文件的分發(fā)接收功能。

2.1.4 多播在線交流模塊 在線交流是網(wǎng)絡(luò)教學(xué)系統(tǒng)的最基本功能，多播在線交流模塊能實(shí)現(xiàn)組內(nèi)成員間(各教學(xué)主體、各網(wǎng)絡(luò)教學(xué)班主持人和參與者)的聊天通信。該模塊在應(yīng)用時(shí)首先需要給參與者起個(gè)用戶名用于表示在多播組內(nèi)的身份，然后加入多播組，就可在線交流。多播在線交流模塊的數(shù)據(jù)傳輸形式和常用的QQ網(wǎng)絡(luò)聊天平臺(tái)不一樣，該在線交流系統(tǒng)不是發(fā)給某一個(gè)確定的人，而是通過IP多播技術(shù)發(fā)給組內(nèi)的所有成員。

2.2 網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)結(jié)構(gòu)

根據(jù)上面所討論的功能模塊的設(shè)計(jì)目標(biāo)和多播對(duì)等設(shè)計(jì)的思想，網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)的系統(tǒng)結(jié)構(gòu)如圖1所示。

圖1 多播網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)結(jié)構(gòu)圖

網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)四個(gè)模塊涉及的“文本、流媒體、圖片及信息”均為網(wǎng)絡(luò)教學(xué)執(zhí)行過程中的重要信息載體，該類資源數(shù)據(jù)以“庫(kù)”文件數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)兩種形式存在著。系統(tǒng)結(jié)構(gòu)圖的每個(gè)功能模塊的實(shí)現(xiàn)步驟相似:學(xué)習(xí)者申請(qǐng)加入某功能模塊的多播組，注冊(cè)并提交網(wǎng)絡(luò)學(xué)習(xí)需求→傳輸系統(tǒng)依托網(wǎng)絡(luò)IP多播和JMF技術(shù)讀取文件流模式網(wǎng)絡(luò)教學(xué)資源數(shù)據(jù)，封裝數(shù)據(jù)到UDP數(shù)據(jù)包并傳輸向網(wǎng)絡(luò)→學(xué)習(xí)者終端接收并組裝教學(xué)資源數(shù)據(jù)→根據(jù)預(yù)先申請(qǐng)加入的模塊功能顯示教學(xué)資源數(shù)據(jù)，傳輸系統(tǒng)進(jìn)而完成網(wǎng)絡(luò)“學(xué)與教”資源數(shù)據(jù)的傳輸任務(wù)。

3 數(shù)據(jù)傳輸系統(tǒng)技術(shù)應(yīng)用案例、關(guān)鍵模塊程序代碼及注意事項(xiàng)

3.1 應(yīng)用案例介紹

案例具體內(nèi)容及實(shí)施過程:在網(wǎng)速為10 Mbps到桌面的局域網(wǎng)上，傳輸一段480MB的MPEG-4格式的流媒體教學(xué)視頻數(shù)據(jù)資源，教學(xué)視頻接收學(xué)生終端數(shù)120人，以“IP 多播 +JMF、UniCast、BroadCast通信技術(shù)”三種模式進(jìn)行對(duì)比實(shí)驗(yàn)。

“Unicast模式”需要對(duì)120個(gè)學(xué)生端分別發(fā)送一份480MB的視頻資源，對(duì)校園網(wǎng)絡(luò)帶寬占用非常大，客戶端資源下載速率只有約4Mbps，網(wǎng)絡(luò)有阻隔現(xiàn)象發(fā)生。若網(wǎng)絡(luò)教學(xué)多媒體資源數(shù)據(jù)量和用戶數(shù)的進(jìn)一步增加，網(wǎng)絡(luò)阻隔、停滯現(xiàn)象會(huì)更加嚴(yán)重，該模式不適合網(wǎng)絡(luò)教學(xué)中大數(shù)據(jù)流多媒體資源的傳輸。

“Broadcast模式”只對(duì)120個(gè)學(xué)生端發(fā)送一份480MB的視頻資源，所有學(xué)生客戶端都必須停下手中的工作，需要獨(dú)立檢查數(shù)據(jù)流向，學(xué)生客戶端的CPU處理資源占有較多，占用高達(dá)近5Mbps的帶寬，客戶端資源下載速率只有約3Mbps。若網(wǎng)絡(luò)教學(xué)多媒體資源數(shù)據(jù)量和用戶數(shù)的進(jìn)一步增加，對(duì)網(wǎng)絡(luò)帶寬的占用和學(xué)生客戶端的CPU處理資源占用會(huì)更加嚴(yán)重，甚至?xí)霈F(xiàn)客戶端死機(jī)現(xiàn)象，該模式不適合網(wǎng)絡(luò)教學(xué)中大數(shù)據(jù)流多媒體資源的傳輸。

“IP多播+JMF模式”只對(duì)120個(gè)學(xué)生客戶端組發(fā)送一份480MB的視頻資源數(shù)據(jù)包，學(xué)生客戶端資源下載速率可達(dá)8Mbps，對(duì)網(wǎng)絡(luò)帶寬和學(xué)生客戶端CPU處理資源的占用都比較少，是多媒體網(wǎng)絡(luò)環(huán)境下網(wǎng)絡(luò)教學(xué)多媒體大數(shù)據(jù)資源傳輸?shù)淖罴逊绞健?/p>

3.2 傳輸系統(tǒng)技術(shù)實(shí)現(xiàn)的關(guān)鍵模塊程序代碼

該研究中關(guān)鍵模塊代碼是用Java語(yǔ)言和SUN公司提供的JMF開發(fā)包進(jìn)行開發(fā)的，包含有Java編程、IP多播網(wǎng)絡(luò)應(yīng)用、JMF包應(yīng)用、多線程技術(shù)等多類知識(shí)［5］。根據(jù)傳輸數(shù)據(jù)類型的不同，關(guān)鍵模塊代碼套接字可分為面向連接的字節(jié)流套接字TCP Socket和無連接的數(shù)據(jù)包套接字UDP Socket兩種類型?？紤]到利用Windows Sockets API編程的繁瑣，該研究采用了MFC封裝的CAsyncSocket和CSocket類成員函數(shù)來進(jìn)行關(guān)鍵模塊代碼設(shè)計(jì)，具體內(nèi)容如下:

3.2.1 加入多播組 學(xué)習(xí)者申請(qǐng)加入多播組功能模塊只需要一次，故需要將相關(guān)的“加入”代碼先行存入多播組類的構(gòu)造函數(shù)中，而可以反復(fù)利用的UDP包僅需一個(gè)即可。

try{socket=new MulticastSocket(port);

ChatGroup=InetAddress.getByName("226.1.4.5");socket setTimeToLive(255);

socket joinGroup(ChatGroup);buffer=new byte［1000］;

datagram=new DatagramPacket(buffer，buffer length);}

上述語(yǔ)句實(shí)現(xiàn)功能:定義由端口號(hào)構(gòu)造的多播組套接字，得到多播組IP地址，設(shè)定多播UDP包的傳輸范圍，將學(xué)習(xí)者終端機(jī)器加入多播組，定義UDP數(shù)據(jù)包的大小，規(guī)范接收端UDP包的具體形態(tài)。

3.2.2 資源端(或教學(xué)資源發(fā)送端) 初始化一個(gè)UDP Socket。調(diào)用 CAsyncSocket的 Create(0，SOCK_DGRAM，0)，SOCK_DGRAM指明該 Socket為 UDP套接字，教學(xué)資源端的iEvent參數(shù)為0，表示不需要得到任何事件發(fā)生的消息。

設(shè)置IP多播數(shù)據(jù)包能通過的路由的數(shù)目。調(diào)用CAsyncSocket的 SetSockOpt(IP_MULTICAST_TTL，＆nTTL，sizeof(int)，IPPROTO_IP)函數(shù)，通過設(shè)置 TTL的值來設(shè)置IP多播數(shù)據(jù)包能通過路由的數(shù)目，在同一網(wǎng)段中應(yīng)設(shè)為“1”，每經(jīng)過一個(gè)路由則相應(yīng)增加“1”。

設(shè)置IP多播數(shù)據(jù)包的LoopBack參數(shù)。調(diào)用CAsyncSocket的 SetSockOpt(IP_MULTICAST_LOOP，＆nLoopBack，sizeof(int)，IPPROTO_IP)函數(shù)，設(shè)置 IP多播數(shù)據(jù)包的LoopBack參數(shù)。若nLoopBack為TRUE，則允許 LoopBack應(yīng)用;若 nLoopBack為 FALSE，則不支持LoopBack。

向IP多播地址發(fā)送數(shù)據(jù)包。調(diào)用CAsyncSocket的 SendTo((char* )pGsmBuffer，GSMBF_SIZE，(SOCKADDR*)＆DestAddr，sizeof(SOCKADDR))。pGsmBuffer表示的是要傳送的數(shù)據(jù)包buffer，DestAddr是目的地址。

向IP多播地址發(fā)送數(shù)據(jù)包結(jié)束。調(diào)用CAsync Socket的Close()函數(shù)關(guān)閉套接字。

3.2.3 數(shù)據(jù)接收端(或?qū)W習(xí)者端) 初始化一個(gè)UDP Socket。調(diào)用 CAsyncSocket的 Create(nGroupPort，SOCK_DGRAM，F(xiàn)D_READ)，nGroupPort是 IP 組播所用的端口，SOCK_DGRAM指明該Socket為UDP套接字，F(xiàn)D_READ表示在套接字得到數(shù)據(jù)時(shí)能得到反饋信息以便于在數(shù)據(jù)載入時(shí)程序能自動(dòng)轉(zhuǎn)入OnReceive()函數(shù)。

套接字地址綁定。bMultipleApps參數(shù)首先設(shè)置為TRUE，然后調(diào)用CAsyncSocket的函數(shù)SetSockOpt(SO_REUSEADDR，(void*)＆bMultipleApps，sizeof(BOOL)，SOL_SOCKET)。

學(xué)習(xí)者加入到指定的IP多播組。調(diào)用API函數(shù) SetSockOpt(m_hSocket，IPPROTO_IP，IP_ADD_MEMBERSHIP，(charFAR*)＆m_mrMReq，sizeof(m_mrMReq))，IP多播組學(xué)習(xí)者終端地址定義在m_mrMReq結(jié)構(gòu)中。

當(dāng)學(xué)習(xí)者終端得到資源發(fā)送端的IP地址和端口后，通過OnReceive()回調(diào)函數(shù)接收數(shù)據(jù)。int nError=ReceiveFrom(m_strBuffer，str_size，m_str SendersIP，m_nSendersPort);其中m_strBuffer為接收數(shù)據(jù)的緩沖區(qū)，m_strSendersIP和m_nSendersPort為得到的教學(xué)資源發(fā)送端的IP地址和端口。

退出IP多播組，終止教學(xué)資源數(shù)據(jù)接收進(jìn)程。調(diào)用 API函數(shù) SetSockOpt(m_hSocket，IPPROTO_IP，IP_DROP_MEMBERSHIP，(charFAR*)＆m_mr MReq，sizeof(m_mrMReq))，然后調(diào)用 CAsyncSocket的Close()函數(shù)關(guān)閉套接字。

3.3 傳輸系統(tǒng)關(guān)鍵程序模塊代碼設(shè)計(jì)的注意事項(xiàng)

IP多播與JMF技術(shù)在網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)的應(yīng)用要重視:利用IP多播技術(shù)及其相關(guān)的多播協(xié)議，充分建立對(duì)等IP多播模型，完成好多模塊的劃分和集成，以便于實(shí)現(xiàn)多模塊間的通信和協(xié)調(diào);應(yīng)建立UDP包封裝分發(fā)和接收組裝的關(guān)鍵協(xié)議代碼，充分研究、應(yīng)用流媒體知識(shí)和JMF包中JMF、JAR的技術(shù);應(yīng)根據(jù)不同文件類型實(shí)現(xiàn)對(duì)不同類文件的調(diào)用和顯示，開發(fā)者應(yīng)強(qiáng)化對(duì)多線程編程和并發(fā)控制知識(shí)的學(xué)習(xí)。另外，在接收端的UDP數(shù)據(jù)包和發(fā)送端的數(shù)據(jù)包形式不同，接收端的UDP包只起一個(gè)容器的作用，程序代碼為:DatagramPacket datagram=new Data-gramPacket(buffer，buffer length);發(fā)送端的 UDP不僅是個(gè)容器，它還封裝了目的地和端口號(hào)，程序代碼為:DatagramPacket dg=new DatagramPacket(buf，buf length，ChatGroup，port)。網(wǎng)絡(luò)教學(xué)用多媒體文件一般都有多個(gè)軌道，每個(gè)軌道都應(yīng)該建立會(huì)話地址，并且一個(gè)軌道對(duì)應(yīng)兩個(gè)端口，不同類型的多媒體文件都用自己的格式，在得到數(shù)據(jù)源后要根據(jù)不同格式來調(diào)整到標(biāo)準(zhǔn)格式。

流媒體文件是網(wǎng)絡(luò)教學(xué)主要的資源數(shù)據(jù)流，利用IP多播技術(shù)、JMF技術(shù)及其RTP/RTCP協(xié)議對(duì)流媒體處理類的設(shè)計(jì)應(yīng)做好對(duì)處理器類，RTP管理器，視頻格式類，格式控制類和監(jiān)聽接口的設(shè)計(jì)，關(guān)鍵代碼如 下［6］:public abstract interface Processor extends Player{};public abstract class RTPManager implements Controls{};public class VideoFormat extends Format{};public abstract interface FormatControl extends Control{};ControllerListener{}，ReceiveStreamListener{}，SessionListener{}。

網(wǎng)絡(luò)教學(xué)的高質(zhì)量需要依靠高效率的數(shù)據(jù)傳輸技術(shù)支撐，基于IP多播與JMF技術(shù)的網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)基本功能可實(shí)現(xiàn):多播組內(nèi)成員聊天;圖片分發(fā)并根據(jù)圖片大小實(shí)時(shí)顯示;文件分發(fā)并根據(jù)不同類型的文件調(diào)用系統(tǒng)的相應(yīng)軟件實(shí)現(xiàn)實(shí)時(shí)顯示;流媒體播放，實(shí)時(shí)接收播放并且不需要安裝播放器。圖1系統(tǒng)還可以通過增加模塊，利用攝像設(shè)備作為數(shù)據(jù)源，就可實(shí)現(xiàn)視頻會(huì)議功能。在目前教學(xué)信息資源以幾何量級(jí)日益豐富的E-Learning時(shí)代，受限于有限的網(wǎng)絡(luò)帶寬條件，IP多播與JMF技術(shù)在網(wǎng)絡(luò)教學(xué)數(shù)據(jù)傳輸系統(tǒng)中必將會(huì)得到廣泛的應(yīng)用，也將會(huì)有很好的應(yīng)用前景。

［1］鄒煉，陳淑珍.IP Multicast在多媒體遠(yuǎn)程安全監(jiān)控系統(tǒng)中的應(yīng)用［J］.計(jì)算機(jī)工程，2001，(8):122-124

［2］蔣海鷗，王之怡，薛原.基于JMF技術(shù)的網(wǎng)絡(luò)視頻監(jiān)控的研究與實(shí)現(xiàn)［J］.網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2007，(8):86-88

［3］周元哲，袁玲.基于JMF技術(shù)實(shí)現(xiàn)流媒體格式的轉(zhuǎn)換［J］.西安郵電學(xué)院學(xué)報(bào)，2005，(7):92-94

［4］劉成德，李祥.基于IP MulticastJMF的多媒體網(wǎng)絡(luò)會(huì)議系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)［J］.計(jì)算機(jī)與數(shù)字工程，2007，(3):132-134，140

［5］林毅，方路平，曾燕.IP Multicast技術(shù)在遠(yuǎn)程教學(xué)系統(tǒng)中的應(yīng)用［J］.計(jì)算機(jī)應(yīng)用，2001，(8):50-51

［6］吳敏強(qiáng)，周俊，朱晴波，等.一種基于RTP/Multicast的流媒體傳輸系統(tǒng)設(shè)計(jì)［J］.計(jì)算機(jī)工程，2004，(9):162-165